lkml.org 
[lkml]   [2019]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
    On Tue, Apr 23, 2019 at 03:26:20PM +0200, Peter Zijlstra wrote:
    > On Tue, Apr 23, 2019 at 06:21:16AM -0700, Paul E. McKenney wrote:
    > > On Tue, Apr 23, 2019 at 02:17:15PM +0200, Peter Zijlstra wrote:
    > > > On Sat, Apr 20, 2019 at 01:54:40AM -0700, Paul E. McKenney wrote:
    > > > > 3. Make non-value-returning atomics provide full ordering.
    > > > > This would of course need some benchmarking, but would be a
    > > > > simple change to make and would eliminate a large class of
    > > > > potential bugs. My guess is that the loss in performance
    > > > > would be non-negligible, but who knows?
    > > >
    > > > Well, only for the architectures that have
    > > > smp_mb__{before,after}_atomic() as barrier(), which are: ia64, mips,
    > > > s390, sparc, x86 and xtense.
    > >
    > > The weakly ordered architectures would need to add the equivalent of
    > > smp_mb() before and after, right? This might result in a more noticeable
    > > loss of performance.
    >
    > The weak archs already have: smp_mb__{before,after}_atomic() :=
    > smp_mb().

    Agreed, but I thought that one of the ideas going forward was to get
    rid of smp_mb__{before,after}_atomic().

    Thanx, Paul

    \
     
     \ /
      Last update: 2019-04-23 22:17    [W:4.633 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site