| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH 00/20] x86: ticket lock rewrite and paravirtualiz
|
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH 00/20] x86: ticket lock rewrite and paravirtualization |
|
From: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Date: |
Fri, 12 Nov 2010 14:20:37 -0800 |
|
Cc: |
Nick Piggin <npiggin@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Srivatsa Vaddagiri <vatsa@xxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Linux Virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx> |
|
Delivery-date: |
Fri, 12 Nov 2010 14:22:04 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4CDDBCE4.80906@xxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<cover.1288794124.git.jeremy.fitzhardinge@xxxxxxxxxx> <4CDDBBD3.5050903@xxxxxxxxx> <4CDDBCE4.80906@xxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc13 Thunderbird/3.1.6 |
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home