From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: vsyscalls may be going away... impact on Xen time performance on Linux in the future? Date: Thu, 09 Jun 2011 15:08:50 -0700 Message-ID: <4DF14472.7050603@goop.org> References: <070733f8-c7aa-4543-85dd-d353088b0e20@default> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <070733f8-c7aa-4543-85dd-d353088b0e20@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, Konrad Wilk List-Id: xen-devel@lists.xenproject.org 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. J