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


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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: vsyscalls may be going away... impact on Xen time performance on Linux in the future?
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 9 Jun 2011 15:39:04 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Thu, 09 Jun 2011 15:39:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DF14472.7050603@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: <070733f8-c7aa-4543-85dd-d353088b0e20@default 4DF14472.7050603@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > 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.

Excellent... thanks for the reassurance.


Xen-devel mailing list

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