search for: __smp_xxx

...sparc: reuse asm-generic/barrier.h arm: reuse asm-generic/barrier.h arm64: reuse asm-generic/barrier.h metag: reuse asm-generic/barrier.h mips: reuse asm-generic/barrier.h x86/um: reuse asm-generic/barrier.h x86: reuse asm-generic/barrier.h asm-generic: add __smp_xxx wrappers powerpc: define __smp_xxx arm64: define __smp_xxx arm: define __smp_xxx blackfin: define __smp_xxx ia64: define __smp_xxx metag: define __smp_xxx mips: define __smp_xxx s390: define __smp_xxx sh: define __smp_xxx, fix smp_store_mb for !...

...sparc: reuse asm-generic/barrier.h arm: reuse asm-generic/barrier.h arm64: reuse asm-generic/barrier.h metag: reuse asm-generic/barrier.h mips: reuse asm-generic/barrier.h x86/um: reuse asm-generic/barrier.h x86: reuse asm-generic/barrier.h asm-generic: add __smp_xxx wrappers powerpc: define __smp_xxx arm64: define __smp_xxx arm: define __smp_xxx blackfin: define __smp_xxx ia64: define __smp_xxx metag: define __smp_xxx mips: define __smp_xxx s390: define __smp_xxx sh: define __smp_xxx, fix smp_store_mb for !...

...> arm: reuse asm-generic/barrier.h > arm64: reuse asm-generic/barrier.h > metag: reuse asm-generic/barrier.h > mips: reuse asm-generic/barrier.h > x86/um: reuse asm-generic/barrier.h > x86: reuse asm-generic/barrier.h > asm-generic: add __smp_xxx wrappers > powerpc: define __smp_xxx > arm64: define __smp_xxx > arm: define __smp_xxx > blackfin: define __smp_xxx > ia64: define __smp_xxx > metag: define __smp_xxx > mips: define __smp_xxx > s390: define __smp_xxx >...

...et of barriers - just because they're prefixed with __* > > unfortunately doesn't stop anyone from using it (been there with > > other arch stuff before.) > > > > I wonder whether we should consider making the smp memory barriers > > inline functions, so these __smp_xxx() variants can be undef'd > > afterwards, thereby preventing drivers getting their hands on these > > new macros? > > That'd be tricky to do cleanly since asm-generic depends on > ifndef to add generic variants where needed. > > But it would be possible to add a...

...et of barriers - just because they're prefixed with __* > > unfortunately doesn't stop anyone from using it (been there with > > other arch stuff before.) > > > > I wonder whether we should consider making the smp memory barriers > > inline functions, so these __smp_xxx() variants can be undef'd > > afterwards, thereby preventing drivers getting their hands on these > > new macros? > > That'd be tricky to do cleanly since asm-generic depends on > ifndef to add generic variants where needed. > > But it would be possible to add a...

On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for arm, > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > This reduces the amount of arch-specific boiler-plate code. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > A...

On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for arm, > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > This reduces the amount of arch-specific boiler-plate code. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > A...

...notate those > specific cases? Using a bunch of per-arch ifdefs in virtio? That's fundamentally what we have now. But basically the rework reduces the LOC count in kernel anyway by moving all ifdef CONFIG_SMP hacks into asm-generic. So why not let virt benefit? Or do you mean wrappers for __smp_XXX that explicitly say they are for talking to host? E.g. pv_mb() pv_rmb() etc. That sounds very reasonable to me. __smp_XXX things then become an implementation detail. > The other memory barriers in the kernel do not matter for SMP'ness > when build UP.

...notate those > specific cases? Using a bunch of per-arch ifdefs in virtio? That's fundamentally what we have now. But basically the rework reduces the LOC count in kernel anyway by moving all ifdef CONFIG_SMP hacks into asm-generic. So why not let virt benefit? Or do you mean wrappers for __smp_XXX that explicitly say they are for talking to host? E.g. pv_mb() pv_rmb() etc. That sounds very reasonable to me. __smp_XXX things then become an implementation detail. > The other memory barriers in the kernel do not matter for SMP'ness > when build UP.

On Sat, Jan 02, 2016 at 11:24:38AM +0000, Russell King - ARM Linux wrote: > On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote: > > This defines __smp_xxx barriers for arm, > > for use by virtualization. > > > > smp_xxx barriers are removed as they are > > defined correctly by asm-generic/barriers.h > > > > This reduces the amount of arch-specific boiler-plate code. > > > > Signed-off-by: Michael S....

This defines __smp_XXX barriers for ia64, for use by virtualization. smp_XXX barriers are removed as they are defined correctly by asm-generic/barriers.h This reduces the amount of arch-specific boiler-plate code. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/ia64/include/asm/barrier.h | 14 +++...

This defines __smp_xxx barriers for sparc, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Arnd Bergmann <arnd at arndb.de> --- arch/sparc/include/asm/barrier_64.h | 8 ++++---- 1...

virtio ring uses smp_wmb on SMP and wmb on !SMP, the reason for the later being that it might be talking to another kernel on the same SMP machine. This is exactly what __smp_XXX barriers do, so switch to these instead of homegrown ifdef hacks. Cc: Peter Zijlstra <peterz at infradead.org> Cc: Alexander Duyck <alexander.duyck at gmail.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/linux/virtio_ring.h | 25 ++++---------------------...

This defines __smp_xxx barriers for arm, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h This reduces the amount of arch-specific boiler-plate code. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Arnd Bergmann <arnd at arndb.de&g...

drivers/xen/xenbus/xenbus_comms.c uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to __smp_XXX barriers which serve this exact purpose. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This is straight-forward, but untested. I can either merge this patchset through my tree if this is acked, or defer this and merge the patchset first, and xen bits through xen tree afterwards....

include/xen/interface/io/ring.h uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to __smp_XXX barriers which serve this exact purpose. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/xen/interface/io/ring.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 7dc...

This defines __smp_xxx barriers for metag, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not use the existing fence() macro since that is defined differently between SMP and !SMP. For th...

This defines __smp_xxx barriers for s390, for use by virtualization. Some smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers unconditionally on this architecture. Signed-off-by: Michael S. Tsirkin <mst at redhat.com>...

...ause they're prefixed with __* > > > unfortunately doesn't stop anyone from using it (been there with > > > other arch stuff before.) > > > > > > I wonder whether we should consider making the smp memory barriers > > > inline functions, so these __smp_xxx() variants can be undef'd > > > afterwards, thereby preventing drivers getting their hands on these > > > new macros? > > > > That'd be tricky to do cleanly since asm-generic depends on > > ifndef to add generic variants where needed. > > > &gt...

On Mon, Jan 04, 2016 at 02:45:25PM +0100, Peter Zijlstra wrote: > On Thu, Dec 31, 2015 at 09:08:38PM +0200, Michael S. Tsirkin wrote: > > This defines __smp_xxx barriers for s390, > > for use by virtualization. > > > > Some smp_xxx barriers are removed as they are > > defined correctly by asm-generic/barriers.h > > > > Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers > > unconditionally on this arch...