search for: dma_

On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:26:29PM +0200, Michael S. Tsirkin wrote: > > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > > > that they use dma_* ops for weak_barriers, while virtio_mb() uses > > > smp_mb(). > > > > It's a hack really. I think I'll clean it up a bit to > > make it more consistent. > > > > To simplify things, you may consider things before > > the optimization brought in...

On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:26:29PM +0200, Michael S. Tsirkin wrote: > > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > > > that they use dma_* ops for weak_barriers, while virtio_mb() uses > > > smp_mb(). > > > > It's a hack really. I think I'll clean it up a bit to > > make it more consistent. > > > > To simplify things, you may consider things before > > the optimization brought in...

...FIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif > > + { > > + WRITE_ONCE(*p, v); > > + mb(); > > + } > > +} > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > that they use dma_* ops for weak_barriers, while virtio_mb() uses > smp_mb(). It's a hack really. I think I'll clean it up a bit to make it more consistent. To simplify things, you may consider things before the optimization brought in by commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 Author: Alexande...

...FIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif > > + { > > + WRITE_ONCE(*p, v); > > + mb(); > > + } > > +} > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > that they use dma_* ops for weak_barriers, while virtio_mb() uses > smp_mb(). It's a hack really. I think I'll clean it up a bit to make it more consistent. To simplify things, you may consider things before the optimization brought in by commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 Author: Alexande...

...t 8:57 AM Christoph Hellwig <hch at lst.de> wrote: > > Add a new API to allocate and free pages that are guaranteed to be > addressable by a device, but otherwise behave like pages allocated by > alloc_pages. The intended APIs to sync them for use with the device > and cpu are dma_sync_single_for_{device,cpu} that are also used for > streaming mappings. > > Switch all drivers over to this new API, but keep the usage of the > crufty dma_cache_sync API for now, which will be cleaned up on a driver > by driver basis. > > Signed-off-by: Christoph Hellwig <...

...gt; > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > > Author: Alexander Duyck <alexander.h.duyck at redhat.com> > > > > Date: Mon Apr 13 21:03:49 2015 +0930 > > > > > > > > virtio_ring: Update weak barriers to use dma_wmb/rmb > > > > > > That commit doesn't make any sense. dma_*mb() explicitly does _NOT_ > > > cover the smp_*mb() part. > > > > > > Again, look at the ARM definitions, the smp_*mb() primitives use the > > > inner coherence stuff, while the...

...gt; > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > > Author: Alexander Duyck <alexander.h.duyck at redhat.com> > > > > Date: Mon Apr 13 21:03:49 2015 +0930 > > > > > > > > virtio_ring: Update weak barriers to use dma_wmb/rmb > > > > > > That commit doesn't make any sense. dma_*mb() explicitly does _NOT_ > > > cover the smp_*mb() part. > > > > > > Again, look at the ARM definitions, the smp_*mb() primitives use the > > > inner coherence stuff, while the...

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >> The advantage to this is that these barriers are available to uniprocessor >> builds as well so the performance should improve under such a >> configurati...

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >> The advantage to this is that these barriers are available to uniprocessor >> builds as well so the performance should improve under such a >> configurati...

On Thu, Dec 17, 2015 at 03:26:29PM +0200, Michael S. Tsirkin wrote: > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > > that they use dma_* ops for weak_barriers, while virtio_mb() uses > > smp_mb(). > > It's a hack really. I think I'll clean it up a bit to > make it more consistent. > > To simplify things, you may consider things before > the optimization brought in by > commit 9e1a27ea42691429e3...

On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif >

On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif >

...Peter Zijlstra wrote: > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > Author: Alexander Duyck <alexander.h.duyck at redhat.com> > > > Date: Mon Apr 13 21:03:49 2015 +0930 > > > > > > virtio_ring: Update weak barriers to use dma_wmb/rmb > > > > That commit doesn't make any sense. dma_*mb() explicitly does _NOT_ > > cover the smp_*mb() part. > > > > Again, look at the ARM definitions, the smp_*mb() primitives use the > > inner coherence stuff, while the dma_*mb() primitives use the o...

...gt; <0f278771-79ce-fe23-e72c-3935dbe82d24 at samsung.com> <20200225112114.GA13686 at intel.com> <3ca785f2-9032-aaf9-0965-8657d31116ba at samsung.com> <20200225154506.GF13686 at intel.com> <20200225192720.GG13686 at intel.com> <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g at mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g at mail.gmail.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1...

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Seems to give a speedup

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Seems to give a speedup

Add a new API to allocate and free pages that are guaranteed to be addressable by a device, but otherwise behave like pages allocated by alloc_pages. The intended APIs to sync them for use with the device and cpu are dma_sync_single_for_{device,cpu} that are also used for streaming mappings. Switch all drivers over to this new API, but keep the usage of the crufty dma_cache_sync API for now, which will be cleaned up on a driver by driver basis. Signed-off-by: Christoph Hellwig <hch at lst.de> --- Documentat...

...in some detail at the top of > > include/linux/virtio.h > > I did read that, it didn't make any sense wrt the code below it. > > For instance it seems to imply weak_barriers is for smp like stuff while > !weak_barriers is for actual devices. > > But then you go use dma_*mb() ops, which are specifially for devices > only for weak_barrier. Yes the dma_*mb thing is a kind of an interface misuse. It's an optimization for UP introduced here: commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 Author: Alexander Duyck <alexander.h.duyck at redhat.com> Date:...

...in some detail at the top of > > include/linux/virtio.h > > I did read that, it didn't make any sense wrt the code below it. > > For instance it seems to imply weak_barriers is for smp like stuff while > !weak_barriers is for actual devices. > > But then you go use dma_*mb() ops, which are specifially for devices > only for weak_barrier. Yes the dma_*mb thing is a kind of an interface misuse. It's an optimization for UP introduced here: commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 Author: Alexander Duyck <alexander.h.duyck at redhat.com> Date:...

...r Duyck wrote: > > On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > >On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: > >>This change makes it so that instead of using smp_wmb/rmb which varies > >>depending on the kernel configuration we can can use dma_wmb/rmb which for > >>most architectures should be equal to or slightly more strict than > >>smp_wmb/rmb. > >> > >>The advantage to this is that these barriers are available to uniprocessor > >>builds as well so the performance should improve under such a...