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.
