[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4A0D3F8C02000078000010A7@vpn.id2.novell.com>
Date: Fri, 15 May 2009 09:10:20 +0100
From: "Jan Beulich" <JBeulich@...ell.com>
To: "Jeremy Fitzhardinge" <jeremy@...p.org>
Cc: "Ingo Molnar" <mingo@...e.hu>,
"Jun Nakajima" <jun.nakajima@...el.com>,
"Xiaohui Xin" <xiaohui.xin@...el.com>, "Xin Li" <xin.li@...el.com>,
"Xen-devel" <xen-devel@...ts.xensource.com>,
"Nick Piggin" <npiggin@...e.de>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Xen-devel] Performance overhead of paravirt_ops on
nativeidentified
>>> Jeremy Fitzhardinge <jeremy@...p.org> 14.05.09 19:45 >>>
>Jan Beulich wrote:
>> Wouldn't a third solution be to use ticket spinlocks everywhere, i.e. eliminate
>> the current indirection, and replace it by an indirection for just the contention
>> case? As I view it, the problem for Xen aren't really the ticket locks by
>> themselves, but rather the extra spinning involved, which is of concern only
>> if a lock is contended. We're using ticket locks quite happily in our kernels,
>> with directed instead of global wakeup from the unlock path.
>Do you have a patch to illustrate what you mean? How do you keep track
>of the target vcpu for the directed wakeup? Are you using the
>event-poll mechanism to block?
A patch for the pv-ops kernel would require some time. What I can give you
right away - just for reference - are the sources we currently use in our kernel:
attached.
Jan
Download attachment "spinlock.h" of type "application/octet-stream" (9518 bytes)
Download attachment "spinlock.c" of type "application/octet-stream" (3835 bytes)
Powered by blists - more mailing lists