Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-07 Thread Linus Torvalds
On Fri, Jun 7, 2019 at 12:27 AM Jan Glauber wrote: > > To clarify, with 224 threads & CPUs queued_spin_lock_slowpath is the top hit > even without a retry limit in lockref. This could be unrelated to the lockref > fallback, it looks like it's coming from the spinlock in: > do_sys_open ->

Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-07 Thread Jan Glauber
On Thu, Jun 06, 2019 at 10:28:12AM +, Jan Glauber wrote: > On Thu, Jun 06, 2019 at 10:41:54AM +0100, Will Deacon wrote: > > On Thu, Jun 06, 2019 at 08:03:27AM +, Jan Glauber wrote: > > > On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > > > > On Wed, Jun 5, 2019 at 6:49 AM

Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-06 Thread Jan Glauber
On Thu, Jun 06, 2019 at 10:41:54AM +0100, Will Deacon wrote: > On Thu, Jun 06, 2019 at 08:03:27AM +, Jan Glauber wrote: > > On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > > > On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > > > > > > > Add an upper bound to the loop to

Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-06 Thread Will Deacon
On Thu, Jun 06, 2019 at 08:03:27AM +, Jan Glauber wrote: > On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > > On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > > > > > Add an upper bound to the loop to force the fallback to spinlocks > > > after some time. A retry value

Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-06 Thread Jan Glauber
On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > > > Add an upper bound to the loop to force the fallback to spinlocks > > after some time. A retry value of 100 should not impact any hardware > > that does not have this issue.

Re: [PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-05 Thread Linus Torvalds
On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > Add an upper bound to the loop to force the fallback to spinlocks > after some time. A retry value of 100 should not impact any hardware > that does not have this issue. > > With the retry limit the performance of an open-close testcase >

[PATCH] lockref: Limit number of cmpxchg loop retries

2019-06-05 Thread Jan Glauber
The lockref cmpxchg loop is unbound as long as the spinlock is not taken. Depending on the hardware implementation of compare-and-swap a high number of loop retries might happen. Add an upper bound to the loop to force the fallback to spinlocks after some time. A retry value of 100 should not