[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyHVYh8VP9r1kohMomw=ed7y_=uQHDxtMsDCEcHKm+tFQ@mail.gmail.com>
Date: Mon, 23 May 2016 10:52:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Boqun Feng <boqun.feng@...il.com>,
Davidlohr Bueso <dave@...olabs.net>,
Manfred Spraul <manfred@...orfullife.com>,
Waiman Long <Waiman.Long@....com>,
Ingo Molnar <mingo@...nel.org>, ggherdovich@...e.com,
Mel Gorman <mgorman@...hsingularity.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Will Deacon <will.deacon@....com>
Subject: Re: sem_lock() vs qspinlocks
On Mon, May 23, 2016 at 5:25 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> Paul has smp_mb__after_unlock_lock() for the RCpc 'upgrade'. How about
> something like:
>
> smp_mb__after_lock()
I'd much rather make the naming be higher level. It's not necessarily
going to be a "mb", and while the problem is about smp, the primitives
it is synchronizing aren't actually smp-specific (ie you're
synchronizing a lock that is relevant on UP too).
So I'd just call it something like
spin_lock_sync_after_lock();
because different locks might have different levels of serialization
(ie maybe a spinlock needs one thing, and a mutex needs another - if
we start worrying about ordering between spin_lock and
mutex_is_locked(), for example, or between mutex_lock() and
spin_is_locked()).
Hmm?
Linus
Powered by blists - more mailing lists