[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16fe117e-32a9-03be-258b-96755bde706a@redhat.com>
Date: Tue, 28 Jul 2020 15:39:12 -0400
From: Waiman Long <longman@...hat.com>
To: Alex Kogan <alex.kogan@...cle.com>, linux@...linux.org.uk,
peterz@...radead.org, mingo@...hat.com, will.deacon@....com,
arnd@...db.de, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
tglx@...utronix.de, bp@...en8.de, hpa@...or.com, x86@...nel.org,
guohanjun@...wei.com, jglauber@...vell.com
Cc: steven.sistare@...cle.com, daniel.m.jordan@...cle.com,
dave.dice@...cle.com
Subject: Re: [PATCH v10 4/5] locking/qspinlock: Introduce starvation avoidance
into CNA
On 4/3/20 4:59 PM, Alex Kogan wrote:
> Keep track of the number of intra-node lock handoffs, and force
> inter-node handoff once this number reaches a preset threshold.
> The default value for the threshold can be overridden with
> the new kernel boot command-line option "numa_spinlock_threshold".
>
> Signed-off-by: Alex Kogan <alex.kogan@...cle.com>
> Reviewed-by: Steve Sistare <steven.sistare@...cle.com>
> Reviewed-by: Waiman Long <longman@...hat.com>
> ---
A major issue with setting a limit on the maximum intra-node lock
transfer is that the worst case latency where a lock can be transferred
to another node is indeterminant. How about changing it to a time-based
limit?
Cheers,
Longman
View attachment "0007-locking-qspinlock-Convert-to-time-based-spinlock-thr.patch" of type "text/x-patch" (5802 bytes)
Powered by blists - more mailing lists