This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: vsyscalls may be going away... impact on Xen time perfor

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] Re: vsyscalls may be going away... impact on Xen time performance on Linux in the future?
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 09 Jun 2011 15:08:50 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Thu, 09 Jun 2011 15:10:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <070733f8-c7aa-4543-85dd-d353088b0e20@default>
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: <070733f8-c7aa-4543-85dd-d353088b0e20@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
On 06/09/2011 02:55 PM, Dan Magenheimer wrote:
> Hmmm...
> It appears that Xen time mechanisms that use vsyscall may be
> getting slower...
> "This is a significant performance penalty (~220ns here) for
> all vsyscall users, but there aren't many left."
> http://lwn.net/Articles/446220/ 
> I honestly don't remember all the details myself anymore,
> but I think this means that user apps in Xen PV domains
> that call gettimeofday a *lot* may be in for a bit of
> a shock when they move to a 3.x kernel in the future.
> (Many enterprise apps do things like timestamp transactions,
> which can lead to 10s of thousands of gettimeofday's
> per second.)

He's talking about vsyscall, but not vdso.  vsyscall mechanism is the
old one where kernel-provided code was mapped into userspace at fixed
addresses which were part of the ABI.  Its only used by very old
versions of glibc.

The newer vdso mechanism provides a full shared object, which contains
symbols for the entrypoints so they don't need to be a fixed addresses
any more.

They're functionally equivalent, so there's no loss of performance from
dropping vsyscalls.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>