lkml.org 
[lkml]   [2010]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/20] x86: ticket lock rewrite and paravirtualization
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



\
 
 \ /
  Last update: 2010-11-12 23:25    [W:0.407 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site