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

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)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel