[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b16a2d2b-3c72-cb70-5b6c-2f02a0953e42@redhat.com>
Date: Wed, 15 Jul 2020 12:33:27 -0400
From: Waiman Long <longman@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Nicholas Piggin <npiggin@...il.com>, Arnd Bergmann <arnd@...db.de>,
Borislav Petkov <bp@...en8.de>,
Davidlohr Bueso <dave@...olabs.net>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will.deacon@....com>, x86@...nel.org
Subject: Re: [PATCH 2/2] locking/pvqspinlock: Optionally store lock holder cpu
into lock
On 7/14/20 5:01 AM, Peter Zijlstra wrote:
> On Mon, Jul 13, 2020 at 10:48:00PM -0400, Waiman Long wrote:
>> Storing the cpu number into the lock can be useful for other reason too. It
>> is not totally related to PPC support.
> Well, the thing you did only works for 'small' (<253 CPU) systems.
> There's a number of Power systems that's distinctly larger than that. So
> it simply cannot work as anything other than a suggestion/hint. It must
> not be a correctness thing.
>
Yes, there are limit on how much data one can put into the lock byte. So
it is not a sure way to find out who the lock holder is. There are
certainly large systems with hundreds or even thousands of cpus, but
they are the minority in the sea of Linux systems out there.
If the lock holder goes through the slowpath, the one behind it can save
its cpu number which can be used a hint of who the lock holder is though
it is not that reliable as lock stealing can happen.
BTW, I did get the optimized PV unlock asm code working now. I will post
the updated unconditional patch later this week for further discussion.
Cheers,
Longman
Powered by blists - more mailing lists