On Thu, Nov 19, 2015 at 06:01:52PM +, Will Deacon wrote:
> For completeness, here's what I've currently got. I've failed to measure
> any performance impact on my 8-core systems, but that's not surprising.
> +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> +{
> + unsigned
On Wed, Nov 18, 2015 at 11:25:14AM +, Will Deacon wrote:
> On Tue, Nov 17, 2015 at 01:01:09PM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 17, 2015 at 11:51:10AM +, Will Deacon wrote:
> > > On Mon, Nov 16, 2015 at 01:58:49PM -0800, Linus Torvalds wrote:
> > > > On Mon, Nov 16, 2015 at 8:2
On Tue, Nov 17, 2015 at 01:01:09PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 17, 2015 at 11:51:10AM +, Will Deacon wrote:
> > On Mon, Nov 16, 2015 at 01:58:49PM -0800, Linus Torvalds wrote:
> > > On Mon, Nov 16, 2015 at 8:24 AM, Will Deacon wrote:
> > > >
> > > > ... or we upgrade spin_unlo
On Tue, Nov 17, 2015 at 11:51:10AM +, Will Deacon wrote:
> Hi Linus,
>
> On Mon, Nov 16, 2015 at 01:58:49PM -0800, Linus Torvalds wrote:
> > On Mon, Nov 16, 2015 at 8:24 AM, Will Deacon wrote:
> > >
> > > ... or we upgrade spin_unlock_wait to a LOCK operation, which might be
> > > slightly ch
Hi Linus,
On Mon, Nov 16, 2015 at 01:58:49PM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2015 at 8:24 AM, Will Deacon wrote:
> >
> > ... or we upgrade spin_unlock_wait to a LOCK operation, which might be
> > slightly cheaper than spin_lock()+spin_unlock().
>
> So traditionally the real concer
On Mon, Nov 16, 2015 at 8:24 AM, Will Deacon wrote:
>
> ... or we upgrade spin_unlock_wait to a LOCK operation, which might be
> slightly cheaper than spin_lock()+spin_unlock().
So traditionally the real concern has been the cacheline ping-pong
part of spin_unlock_wait(). I think adding a memory
On Mon, Nov 16, 2015 at 04:46:36PM +, Will Deacon wrote:
> On Mon, Nov 16, 2015 at 08:44:43AM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 16, 2015 at 04:24:53PM +, Will Deacon wrote:
> > > On Mon, Nov 16, 2015 at 05:04:45PM +0100, Peter Zijlstra wrote:
> > > > On Mon, Nov 16, 2015 at 04:
On Mon, Nov 16, 2015 at 08:44:43AM -0800, Paul E. McKenney wrote:
> On Mon, Nov 16, 2015 at 04:24:53PM +, Will Deacon wrote:
> > On Mon, Nov 16, 2015 at 05:04:45PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 16, 2015 at 04:56:58PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 12, 2015 at
On Mon, Nov 16, 2015 at 04:24:53PM +, Will Deacon wrote:
> On Mon, Nov 16, 2015 at 05:04:45PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 16, 2015 at 04:56:58PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 12, 2015 at 10:21:39AM -0800, Linus Torvalds wrote:
> > > > Now, the point of spin_unl
On Mon, Nov 16, 2015 at 05:04:45PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 16, 2015 at 04:56:58PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 12, 2015 at 10:21:39AM -0800, Linus Torvalds wrote:
> > > Now, the point of spin_unlock_wait() (and "spin_is_locked()") should
> > > generally be that yo
On Mon, Nov 16, 2015 at 04:56:58PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 12, 2015 at 10:21:39AM -0800, Linus Torvalds wrote:
> > Now, the point of spin_unlock_wait() (and "spin_is_locked()") should
> > generally be that you have some external ordering guarantee that
> > guarantees that the loc
On Thu, Nov 12, 2015 at 10:21:39AM -0800, Linus Torvalds wrote:
> Now, the point of spin_unlock_wait() (and "spin_is_locked()") should
> generally be that you have some external ordering guarantee that
> guarantees that the lock has been taken. For example, for the IPC
> semaphores, we do either on
Hi Paul,
On Thu, Nov 12, 2015 at 03:43:51PM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2015 at 09:33:39PM +, Will Deacon wrote:
> > I think we ended up concluding that smp_mb__after_unlock_lock is indeed
> > required, but I don't think we should just resurrect the old definition,
> > whi
On Thu, Nov 12, 2015 at 09:33:39PM +, Will Deacon wrote:
> On Thu, Nov 12, 2015 at 10:59:06AM -0800, Paul E. McKenney wrote:
> > On Thu, Nov 12, 2015 at 08:33:02PM +0100, Oleg Nesterov wrote:
> > > On 11/12, Peter Zijlstra wrote:
> > > >
> > > > On Thu, Nov 12, 2015 at 07:38:07PM +0100, Oleg Ne
On Thu, Nov 12, 2015 at 10:21:39AM -0800, Linus Torvalds wrote:
> On Wed, Nov 11, 2015 at 11:14 PM, Boqun Feng wrote:
> >
> > Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> > only guarantees that the memory operations following spin_lock() can't
> > be reorder before the
On Thu, Nov 12, 2015 at 07:02:51AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2015 at 10:49:02PM +0800, Boqun Feng wrote:
> > On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> > [snip]
> > >
> > > I cannot resist suggesting that any lock that interacts with
> > > spin_unloc
On Thu, Nov 12, 2015 at 10:59:06AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2015 at 08:33:02PM +0100, Oleg Nesterov wrote:
> > On 11/12, Peter Zijlstra wrote:
> > >
> > > On Thu, Nov 12, 2015 at 07:38:07PM +0100, Oleg Nesterov wrote:
> > > > It seems that PPC needs to define smp_mb__before_
[sorry for the late reply, I'm away from my desk until Monday since I'm
busy with family issues]
On Thu, Nov 12, 2015 at 07:20:42AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2015 at 04:08:22PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 12, 2015 at 07:01:49AM -0800, Paul E. McKenney wrote
On Thu, Nov 12, 2015 at 08:33:02PM +0100, Oleg Nesterov wrote:
> On 11/12, Peter Zijlstra wrote:
> >
> > On Thu, Nov 12, 2015 at 07:38:07PM +0100, Oleg Nesterov wrote:
> > > It seems that PPC needs to define smp_mb__before_spinlock() as full mb(),
> > > no?
> >
> > It does:
> >
> > arch/powerpc/inc
On 11/12, Peter Zijlstra wrote:
>
> On Thu, Nov 12, 2015 at 07:38:07PM +0100, Oleg Nesterov wrote:
> > It seems that PPC needs to define smp_mb__before_spinlock() as full mb(),
> > no?
>
> It does:
>
> arch/powerpc/include/asm/barrier.h:#define smp_mb__before_spinlock() smp_mb()
Ah, indeed, thanks
On Wed, Nov 11, 2015 at 11:14 PM, Boqun Feng wrote:
>
> Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> only guarantees that the memory operations following spin_lock() can't
> be reorder before the *LOAD* part of spin_lock() not the *STORE* part,
> i.e. the case below ca
On Thu, Nov 12, 2015 at 07:38:07PM +0100, Oleg Nesterov wrote:
> It seems that PPC needs to define smp_mb__before_spinlock() as full mb(),
> no?
It does:
arch/powerpc/include/asm/barrier.h:#define smp_mb__before_spinlock() smp_mb()
--
To unsubscribe from this list: send the line "unsubscribe lin
On 11/12, Boqun Feng wrote:
>
> On Thu, Nov 12, 2015 at 04:00:58PM +0100, Oleg Nesterov wrote:
> >
> > No?
> >
>
> do_exit() is surely buggy if spin_lock() could work in this way.
OK, good ;) so we need to fix spin_lock() on PPC ? Or add
mb__after_unlock_lock() but this leads to other questions...
On Thu, Nov 12, 2015 at 10:49:02PM +0800, Boqun Feng wrote:
> On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> [snip]
> >
> > I cannot resist suggesting that any lock that interacts with
> > spin_unlock_wait() must have all relevant acquisitions followed by
> > smp_mb__after_unl
On Thu, Nov 12, 2015 at 04:08:22PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 12, 2015 at 07:01:49AM -0800, Paul E. McKenney wrote:
> > On Thu, Nov 12, 2015 at 03:50:13PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> > > > I cannot resist sug
On Thu, Nov 12, 2015 at 04:00:58PM +0100, Oleg Nesterov wrote:
> On 11/12, Boqun Feng wrote:
[snip]
> >
> > Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> > only guarantees that the memory operations following spin_lock() can't
> > be reorder before the *LOAD* part of spi
On Thu, Nov 12, 2015 at 07:01:49AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2015 at 03:50:13PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> > > I cannot resist suggesting that any lock that interacts with
> > > spin_unlock_wait() must
On Thu, Nov 12, 2015 at 03:50:13PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> > I cannot resist suggesting that any lock that interacts with
> > spin_unlock_wait() must have all relevant acquisitions followed by
> > smp_mb__after_unlock_lock()
On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
> I cannot resist suggesting that any lock that interacts with
> spin_unlock_wait() must have all relevant acquisitions followed by
> smp_mb__after_unlock_lock().
Ha! that would certainly help here. But it would mean that argh64v8 a
On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
[snip]
>
> I cannot resist suggesting that any lock that interacts with
> spin_unlock_wait() must have all relevant acquisitions followed by
> smp_mb__after_unlock_lock().
>
But
1. This would expand the purpose of smp_mb__af
On Thu, Nov 12, 2015 at 04:00:58PM +0100, Oleg Nesterov wrote:
> On 11/12, Boqun Feng wrote:
> >
> > On Wed, Nov 11, 2015 at 08:39:53PM +0100, Oleg Nesterov wrote:
> > >
> > > object_t *object;
> > > spinlock_t lock;
> > >
> > > void update(void)
> > > {
> > > object_t *o;
> > >
>
On 11/12, Boqun Feng wrote:
>
> On Wed, Nov 11, 2015 at 08:39:53PM +0100, Oleg Nesterov wrote:
> >
> > object_t *object;
> > spinlock_t lock;
> >
> > void update(void)
> > {
> > object_t *o;
> >
> > spin_lock(&lock);
> > o = READ_ONCE(object);
> >
On Wed, Nov 11, 2015 at 06:34:56PM +0800, Boqun Feng wrote:
> On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> > Hi Oleg,
> >
> > On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
> > [snip]
> > >
> > > Unfortunately this doesn't look exactly right...
> > >
> > > spin_u
On Thu, Nov 12, 2015 at 03:14:51PM +0800, Boqun Feng wrote:
> Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> only guarantees that the memory operations following spin_lock() can't
> be reorder before the *LOAD* part of spin_lock() not the *STORE* part,
> i.e. the case bel
On Wed, Nov 11, 2015 at 08:39:53PM +0100, Oleg Nesterov wrote:
> On 11/11, Peter Zijlstra wrote:
> >
> > On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> >
> > > Just be curious, should spin_unlock_wait() semantically be an ACQUIRE?
> >
> > I did wonder the same thing, it would simplif
On Wed, Nov 11, 2015 at 11:39 AM, Oleg Nesterov wrote:
> On 11/11, Peter Zijlstra wrote:
>
> Sometimes I even think it should have both ACQUIRE + RELEASE semantics.
> IOW, it should be "equivalent" to spin_lock() + spin_unlock().
That's insane.
"Release" semantics are - by definition - about stu
He Boqun,
Let me first state that I can't answer authoritatively when it comes to
barriers. That said,
On 11/11, Boqun Feng wrote:
>
> But still, there is one suspicious use of smp_mb() in do_exit():
>
> /*
>* The setting of TASK_RUNNING by try_to_wake_up() may be delayed
>*
On 11/11, Peter Zijlstra wrote:
>
> On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
>
> > Just be curious, should spin_unlock_wait() semantically be an ACQUIRE?
>
> I did wonder the same thing, it would simplify a number of things if
> this were so.
Yes, me too.
Sometimes I even think
On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> Just be curious, should spin_unlock_wait() semantically be an ACQUIRE?
I did wonder the same thing, it would simplify a number of things if
this were so.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> Hi Oleg,
>
> On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
> [snip]
> >
> > Unfortunately this doesn't look exactly right...
> >
> > spin_unlock_wait() is not equal to "while (locked) relax", the latter
> > is live-lo
Hi Oleg,
On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
[snip]
>
> Unfortunately this doesn't look exactly right...
>
> spin_unlock_wait() is not equal to "while (locked) relax", the latter
> is live-lockable or at least sub-optimal: we do not really need to spin
Just be curious
On Tue, Nov 03, 2015 at 08:43:22PM -0800, Linus Torvalds wrote:
> On Tue, Nov 3, 2015 at 7:57 PM, Paul E. McKenney
> wrote:
> >
> > Thank you, and yes, it clearly states that read-to-write dependencies
> > are ordered.
>
> Well, I wouldn't say that it's exactly "clear".
>
> The fact that they ex
On Tue, Nov 3, 2015 at 7:57 PM, Paul E. McKenney
wrote:
>
> Thank you, and yes, it clearly states that read-to-write dependencies
> are ordered.
Well, I wouldn't say that it's exactly "clear".
The fact that they explicitly say "Note that the DP relation does not
directly impose a BEFORE (⇐) orde
On Tue, Nov 03, 2015 at 11:40:24AM -0800, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 5:57 PM, Paul E. McKenney
> wrote:
[ . . . ]
> > I am in India and my Alpha Architecture Manual is in the USA.
>
> I sent you a link to something that should work, and that has the section.
Thank you, and
On Mon, Nov 2, 2015 at 5:57 PM, Paul E. McKenney
wrote:
>>
>> Alpha isn't special. And smp_read_barrier_depends() hasn't magically
>> become something new.
>
> The existing control dependencies (READ_ONCE_CTRL() and friends) only
> guarantee ordering against later stores, and not against later loa
On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
> > - raw_spin_unlock_wait(&task->pi_lock);
> > - smp_mb();
> > + smp_cond_acquire(!raw_spin_is_locked(&task->pi_lock));
>
> Unfortunately this doesn't look exactly right...
>
> spin_unlock_wait() is not
On 11/02, Peter Zijlstra wrote:
>
> +#define smp_cond_acquire(cond) do {\
> + while (!(cond)) \
> + cpu_relax();\
> + smp_read_barrier_depends(); /* ctrl */ \
> + smp_rmb(); /* ctrl + rmb := acquire */ \
> +} wh
On Mon, Nov 02, 2015 at 11:17:17AM -0800, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 10:37 AM, Will Deacon wrote:
> > On Mon, Nov 02, 2015 at 10:08:24AM -0800, Linus Torvalds wrote:
> >> On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra
> >> wrote:
> >> > +#define smp_cond_acquire(cond) do {
On Mon, Nov 2, 2015 at 5:14 PM, Paul E. McKenney
wrote:
>
> You would ask that question when I am many thousands of miles from my
> copy of the Alpha reference manual! ;-)
I don't think I've touched a paper manual in years. Too m uch effort
to index and search. Look here
http://download.maji
On Mon, Nov 02, 2015 at 05:43:48PM +, Will Deacon wrote:
> On Mon, Nov 02, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 02, 2015 at 02:29:05PM +0100, Peter Zijlstra wrote:
> >
> > > Note that while smp_cond_acquire() has an explicit
> > > smp_read_barrier_depends() for Alpha
On Mon, Nov 02, 2015 at 11:17:17AM -0800, Linus Torvalds wrote:
> As to READ_ONCE_CTRL - two wrongs don't make a right.
>
> That smp_read_barrier_depends() there doesn't make any sense either.
>
> And finally, the alpha architecture manual actually does have the
> notion of "Dependence Constraint
On Mon, Nov 2, 2015 at 12:36 PM, David Howells wrote:
> Linus Torvalds wrote:
>
>> > + smp_read_barrier_depends(); /* ctrl */ \
>> > + smp_rmb(); /* ctrl + rmb := acquire */ \
>
> Doesn't smp_rmb() imply an smp_read_barrier_depends() anyway?
Yes, it does. But that "smp_read_barrier
On Mon, Nov 02, 2015 at 08:36:49PM +, David Howells wrote:
> Linus Torvalds wrote:
>
> > > + smp_read_barrier_depends(); /* ctrl */ \
> > > + smp_rmb(); /* ctrl + rmb := acquire */ \
>
> Doesn't smp_rmb() imply an smp_read_barrier_depends() anyway? In
> memory-barriers.txt, it
Linus Torvalds wrote:
> > + smp_read_barrier_depends(); /* ctrl */ \
> > + smp_rmb(); /* ctrl + rmb := acquire */ \
Doesn't smp_rmb() imply an smp_read_barrier_depends() anyway? In
memory-barriers.txt, it says:
Read memory barriers imply data dependency barriers, and so can
On Mon, Nov 02, 2015 at 07:57:09PM +, Will Deacon wrote:
> > >> smp_read_barrier_depends() is about a memory barrier where there is a
> > >> data dependency between two accesses. The "depends" is very much about
> > >> the data dependency, and very much about *nothing* else.
> > >
> > > Paul wa
On Mon, Nov 02, 2015 at 11:17:17AM -0800, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 10:37 AM, Will Deacon wrote:
> > On Mon, Nov 02, 2015 at 10:08:24AM -0800, Linus Torvalds wrote:
> >> On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra
> >> wrote:
> >> > +#define smp_cond_acquire(cond) do {
On Mon, Nov 2, 2015 at 10:37 AM, Will Deacon wrote:
> On Mon, Nov 02, 2015 at 10:08:24AM -0800, Linus Torvalds wrote:
>> On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra wrote:
>> > +#define smp_cond_acquire(cond) do {\
>> > + while (!(cond)) \
>> > +
On Mon, Nov 02, 2015 at 10:08:24AM -0800, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra wrote:
> > +#define smp_cond_acquire(cond) do {\
> > + while (!(cond)) \
> > + cpu_relax();\
> > + smp_
On Mon, Nov 2, 2015 at 5:29 AM, Peter Zijlstra wrote:
> +#define smp_cond_acquire(cond) do {\
> + while (!(cond)) \
> + cpu_relax();\
> + smp_read_barrier_depends(); /* ctrl */ \
> + smp_rmb(); /* ctrl + rmb :
On Mon, Nov 02, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 02, 2015 at 02:29:05PM +0100, Peter Zijlstra wrote:
>
> > Note that while smp_cond_acquire() has an explicit
> > smp_read_barrier_depends() for Alpha, neither sites it gets used in
> > were actually buggy on Alpha for th
Hi Peter,
On Mon, Nov 02, 2015 at 02:29:05PM +0100, Peter Zijlstra wrote:
> Introduce smp_cond_acquire() which combines a control dependency and a
> read barrier to form acquire semantics.
>
> This primitive has two benefits:
> - it documents control dependencies,
> - its typically cheaper than
On Mon, Nov 02, 2015 at 02:29:05PM +0100, Peter Zijlstra wrote:
> Note that while smp_cond_acquire() has an explicit
> smp_read_barrier_depends() for Alpha, neither sites it gets used in
> were actually buggy on Alpha for their lack of it. The first uses
> smp_rmb(), which on Alpha is a full barri
Introduce smp_cond_acquire() which combines a control dependency and a
read barrier to form acquire semantics.
This primitive has two benefits:
- it documents control dependencies,
- its typically cheaper than using smp_load_acquire() in a loop.
Note that while smp_cond_acquire() has an explici
63 matches
Mail list logo
