Re: [PATCH v4 next 1/9] locking/osq_lock: Add some comments about how it works

[Waiman Long]

On 9/7/26 4:41 AM, David Laight wrote:
> No code changes, just some extra explanations.
>
> Signed-off-by: David Laight <david.laight.linux@xxxxxxxxx>
> ---
>   kernel/locking/osq_lock.c | 27 ++++++++++++++++++++++++---
>   1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> index b4233dc2c2b0..b17aa704c449 100644
> --- a/kernel/locking/osq_lock.c
> +++ b/kernel/locking/osq_lock.c
> @@ -4,12 +4,33 @@
>   #include <linux/osq_lock.h>
>   
>   /*
> - * An MCS like lock especially tailored for optimistic spinning for sleeping
> - * lock implementations (mutex, rwsem, etc).
> + * An MCS like spin lock especially tailored for optimistic spinning for
> + * sleeping lock implementations (mutex, rwsem, etc).
> + * Each CPU spins on a local variable to avoid cache-line bounces.
>    *
> - * Using a single mcs node per CPU is safe because sleeping locks should not be
> + * The CPU that holds the osq_lock checks the mutex/rwsem, the other CPU spin
> + * in osq_lock() until either the osq_lock is obtained or the scheduler
> + * requests the process be preempted.
> + *
> + * Using a single osq node per CPU is safe because sleeping locks should not be
>    * called from interrupt context and we have preemption disabled while
>    * spinning.
> + *
> + * The osq_nodes for the spinning CPU are put on a double-linked (non circular)
> + * list. The list 'pointers' can either be the address of the osq_node or the
> + * associated CPU number, the CPU numbers are offset by one so that zero can
> + * be used like a NULL ponter.

Typo: "ponter" -> "pointer".

This description seems to describe the optimistic_spin_node structure 
after patch 2. So should you swap patch 1 and 2 to be more accurate?

Saying that 'pointers' can either be the osq_node address or the 
associated CPU numbers is a bit vague. next is the osq_node address and 
prev is the offset'ed CPU numbers. It is not really either one or the 
other. Other than that, the description looks good.

Cheers,
Longman