Re: [PATCH 00/20] x86: ticket lock rewrite and paravirtualization

["H. Peter Anvin" <hpa@zytor.com>]

On 11/12/2010 02:17 PM, Jeremy Fitzhardinge wrote:
> On 11/12/2010 02:12 PM, H. Peter Anvin wrote:
>> On 11/03/2010 07:59 AM, Jeremy Fitzhardinge wrote:
>>>       - with an unmodified struct spinlock, it can check to see if
>>>         head == tail after unlock; if not, then there's someone else
>>>         trying to lock, and we can do a kick.  Unfortunately this
>>>         generates very high level of redundant kicks, because the
>>>         waiting CPU might not have blocked yet (which is the common
>>>         case)
>>>
>> How high is "very high" here -- most of the time (so that any mitigation
>> on the slow patch is useless)?
> 
> I'll need to remeasure, but I think around 90% of the slowpath entries
> were spurious without this.  In other words, when spinlocks do contend,
> most of the time it isn't very serious and the other cpu doesn't spend
> much time spinning.
> 

90% of the slowpath entries is one thing, my real question is the
fraction of fastpath entries that get diverted to the slowpath.  It
affects where mitigation needs to happen.

	-hpa