Re: [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code

2023-12-30 Thread Waiman Long
On 12/30/23 17:39, David Laight wrote: From: Linus Torvalds Sent: 30 December 2023 19:41 On Fri, 29 Dec 2023 at 12:52, David Laight wrote: David Laight (5): Move the definition of optimistic_spin_node into osf_lock.c Clarify osq_wait_next() I took these two as preparatory independent

RE: [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code

2023-12-30 Thread David Laight
From: Linus Torvalds > Sent: 30 December 2023 19:41 > > On Fri, 29 Dec 2023 at 12:52, David Laight wrote: > > > > David Laight (5): > > Move the definition of optimistic_spin_node into osf_lock.c > > Clarify osq_wait_next() > > I took these two as preparatory independent patches, with that >

Re: [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code

2023-12-30 Thread Linus Torvalds
On Fri, 29 Dec 2023 at 12:52, David Laight wrote: > > David Laight (5): > Move the definition of optimistic_spin_node into osf_lock.c > Clarify osq_wait_next() I took these two as preparatory independent patches, with that osq_wait_next() clarification split into two. I also did the renaming

[PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code

2023-12-29 Thread David Laight
Zeng Heng noted that heavy use of the osq (optimistic spin queue) code used rather more cpu than might be expected. See: https://lore.kernel.org/lkml/202312210155.wc2huk8c-...@intel.com/T/#mcc46eedd1ef22a0d668828b1d088508c9b1875b8 Part of the problem is there is a pretty much guaranteed cache line