Re: [PATCH 2/2] locking/pvqspinlock: Optionally store lock holder cpu into lock

[Waiman Long]

On 7/12/20 1:34 PM, Peter Zijlstra wrote:
> On Sat, Jul 11, 2020 at 02:21:28PM -0400, Waiman Long wrote:
> > The previous patch enables native qspinlock to store lock holder cpu
> > number into the lock word when the lock is acquired via the slowpath.
> > Since PV qspinlock uses atomic unlock, allowing the fastpath and
> > slowpath to put different values into the lock word will further slow
> > down the performance. This is certainly undesirable.
> >
> > The only way we can do that without too much performance impact is to
> > make fastpath and slowpath put in the same value. Still there is a slight
> > performance overhead in the additional access to a percpu variable in the
> > fastpath as well as the less optimized x86-64 PV qspinlock unlock path.
> >
> > A new config option QUEUED_SPINLOCKS_CPUINFO is now added to enable
> > distros to decide if they want to enable lock holder cpu information in
> > the lock itself for both native and PV qspinlocks across both fastpath
> > and slowpath. If this option is not configureed, only native qspinlocks
> > in the slowpath will put the lock holder cpu information in the lock
> > word.
> And this kills it,.. if it doesn't make unconditional sense, we're not
> going to do this. It's just too ugly.
You mean it has to be unconditional, no option config if we want to do 
it. Right?

It can certainly be made unconditional after I figure out how to make 
the optimized PV unlock code work.

Cheers,
Longman