vsyscalls may be going away... impact on Xen time performance on Linux in the future?

vsyscalls may be going away... impact on Xen time performance on Linux in the future?

[Dan Magenheimer]

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.)

See the xen-devel discussion here:

http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00872.html 

Dan

P.S. For lwn subscribers (or non-subscribers willing to wait a week),
see Jonathan Corbet's nice overview at http://lwn.net/Articles/446125/ 

--

Thanks... for the memory!
I really could use more / my throughput's on the floor
The balloon is flat / my swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to Bob Hope)

Re: vsyscalls may be going away... impact on Xen time performance on Linux in the future?

[Jeremy Fitzhardinge]

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

RE: Re: vsyscalls may be going away... impact on Xen time performance on Linux in the future?

[Dan Magenheimer]

> > 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.

Dan