Re: [Xen-devel] Re: NPTL/TLS "emulation" idea (fwd)

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > With no /lib/tls this takes ~180ms. With emulation it takes
> > ~300ms. With the new technique it's ~390ms -- so about a further 30%
> > slowdown, or 115% slowdown overall.
> 
> Considering how system heavy this workload is, that's
> probably not even that bad.

200ms of pure CPU overhead is abysmal!

> > The extra cost is due to the fact that we fault nearly twice as often
> > because -ve and +ve accesses seem pretty neatly interleaved. So we
> > fault on all GS accesses, rather than just the -ve ones. :-(
> 
> IIRC the glibc private data is accessed once per system
> call, or possibly on both system call entrance and exit.
> 
> Less system heavy tasks probably do not have an overhead
> as bad as ls -R.

Just booting a minimal Fedora Core distribution takes 2.5 *million*
faults. The slowdown is noticeable.

More feasible long-term solutions include:

 1. Modify the ABI to disallow -ve accesses [sounds like this
    possibility is vetoed by Ulrich Drepper].

 2. Provide alternative apps/libraries that do not cause -ve accesses.

 3. If both FS and GS are reserved for glibc, we could indeed have one
    for +ve accesses and one for -ve accesses. This oculd be
    implemented either in user space --- i.e., rewrite glibc, and
    possibly gcc, to use both registers --- or by binary rewriting in
    the kernel (but problems with the patches getting committed to
    disc!!). 

 -- Keir


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel