Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1385330 > unrolled thread

Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Boqun Feng <boqun.feng@gmail.com> - 2016-04-22 18:10 +0200
    Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Will Deacon <will.deacon@arm.com> - 2016-04-22 19:00 +0200
      Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Boqun Feng <boqun.feng@gmail.com> - 2016-04-23 06:00 +0200
    Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Peter Zijlstra <peterz@infradead.org> - 2016-04-23 04:40 +0200
      Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Boqun Feng <boqun.feng@gmail.com> - 2016-04-23 05:40 +0200

#1385330 — Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait()

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote:
[...]
> > +static inline void __cmpwait(volatile void *ptr, unsigned long val, int size)
> > +{
> > +	switch (size) {
> > +	case 1: return __cmpwait_case_1(ptr, val);
> > +	case 2: return __cmpwait_case_2(ptr, val);
> > +	case 4: return __cmpwait_case_4(ptr, val);
> > +	case 8: return __cmpwait_case_8(ptr, val);
> > +	default: BUILD_BUG();
> > +	}
> > +
> > +	unreachable();
> > +}
> > +
> > +#define cmpwait(ptr, val) \
> > +	__cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr)))
> 
> We might want to call this cmpwait_relaxed, in case we decide to add
> fenced versions in the future. Or just make it cmpwait_acquire and
> remove the smp_rmb() from smp_cond_load_acquire(). Dunno.
> 

How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()?
This barrier is designed to provide an ACQUIRE ordering when combining a
cmpwait() .

And cmpwait() only has minimal ordering guarantee, but if it is actually
an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
is just empty.

We might need this special barrier on ppc, because we can implement it
with "isync" given that cmpwait() has control dependency and ctrl+isync
is ACQUIRE on ppc.

Thoughts?

Regards,
Boqun

> Will

[toc] | [next] | [standalone]

#1385357

On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote:
> On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote:
> [...]
> > > +static inline void __cmpwait(volatile void *ptr, unsigned long val, int size)
> > > +{
> > > +	switch (size) {
> > > +	case 1: return __cmpwait_case_1(ptr, val);
> > > +	case 2: return __cmpwait_case_2(ptr, val);
> > > +	case 4: return __cmpwait_case_4(ptr, val);
> > > +	case 8: return __cmpwait_case_8(ptr, val);
> > > +	default: BUILD_BUG();
> > > +	}
> > > +
> > > +	unreachable();
> > > +}
> > > +
> > > +#define cmpwait(ptr, val) \
> > > +	__cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr)))
> > 
> > We might want to call this cmpwait_relaxed, in case we decide to add
> > fenced versions in the future. Or just make it cmpwait_acquire and
> > remove the smp_rmb() from smp_cond_load_acquire(). Dunno.
> > 
> 
> How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()?
> This barrier is designed to provide an ACQUIRE ordering when combining a
> cmpwait() .
> 
> And cmpwait() only has minimal ordering guarantee, but if it is actually
> an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
> is just empty.

Maybe, but that makes it difficult for me to use a load-acquire instruction
for the ACQUIRE case.

Will

[toc] | [prev] | [next] | [standalone]

#1385569

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 22, 2016 at 05:53:11PM +0100, Will Deacon wrote:
> On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote:
> > On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote:
> > [...]
> > > > +static inline void __cmpwait(volatile void *ptr, unsigned long val, int size)
> > > > +{
> > > > +	switch (size) {
> > > > +	case 1: return __cmpwait_case_1(ptr, val);
> > > > +	case 2: return __cmpwait_case_2(ptr, val);
> > > > +	case 4: return __cmpwait_case_4(ptr, val);
> > > > +	case 8: return __cmpwait_case_8(ptr, val);
> > > > +	default: BUILD_BUG();
> > > > +	}
> > > > +
> > > > +	unreachable();
> > > > +}
> > > > +
> > > > +#define cmpwait(ptr, val) \
> > > > +	__cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr)))
> > > 
> > > We might want to call this cmpwait_relaxed, in case we decide to add
> > > fenced versions in the future. Or just make it cmpwait_acquire and
> > > remove the smp_rmb() from smp_cond_load_acquire(). Dunno.
> > > 
> > 
> > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()?
> > This barrier is designed to provide an ACQUIRE ordering when combining a
> > cmpwait() .
> > 
> > And cmpwait() only has minimal ordering guarantee, but if it is actually
> > an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
> > is just empty.
> 
> Maybe, but that makes it difficult for me to use a load-acquire instruction
> for the ACQUIRE case.
> 

You're right. I was missting that point. Please ignore this proposal.

So I think having a cmpwait_relaxed makes more sense for the people
knowing they could only rely on the control dependency? Or we actually
don't want to encourage this kind of people ;-)

Regards,
Boqun

> Will

[toc] | [prev] | [next] | [standalone]

#1385563

On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote:
> How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()?
> This barrier is designed to provide an ACQUIRE ordering when combining a
> cmpwait() .

That's a horrible name for a barrier :-)

> And cmpwait() only has minimal ordering guarantee, but if it is actually
> an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
> is just empty.
> 
> We might need this special barrier on ppc, because we can implement it
> with "isync" given that cmpwait() has control dependency and ctrl+isync
> is ACQUIRE on ppc.
> 
> Thoughts?

Provide a PPC specific smp_cond_load_acquire() using ISYNC ?

[toc] | [prev] | [next] | [standalone]

#1385566

[Multipart message — attachments visible in raw view] — view raw

On Sat, Apr 23, 2016 at 04:37:36AM +0200, Peter Zijlstra wrote:
> On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote:
> > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()?
> > This barrier is designed to provide an ACQUIRE ordering when combining a
> > cmpwait() .
> 
> That's a horrible name for a barrier :-)
> 

Indeed, and having another special barrier is a pain.

> > And cmpwait() only has minimal ordering guarantee, but if it is actually
> > an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
> > is just empty.
> > 
> > We might need this special barrier on ppc, because we can implement it
> > with "isync" given that cmpwait() has control dependency and ctrl+isync
> > is ACQUIRE on ppc.
> > 
> > Thoughts?
> 
> Provide a PPC specific smp_cond_load_acquire() using ISYNC ?

That works, but I should do more investigation on that, I brought this
up because ISYNC may be better than smp_rmb() in two cases, IIUC:

1.	for old systems without LWSYNC, smp_rmb() is actually SYNC,
	which is heavier than ISYNC.

2.	for new systems, isync may be a little faster than lwsync,
	according to Michael Ellerman: http://lkml.kernel.org/g/1437012028.28475.2.camel@ellerman.id.au

but I doubt these two cases will have any observed performance impact,
so the current version of smp_cond_load_acquire() in your patch is fine,
and we can switch to a specific one in the future we want to ;-)

Regards,
Boqun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web