WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Rik van Riel <riel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: NPTL/TLS "emulation" idea (fwd)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 20 Oct 2004 16:32:40 +0100
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, jakub@xxxxxxxxxx, roland@xxxxxxxxxx
Delivery-date: Wed, 20 Oct 2004 16:43:26 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 20 Oct 2004 10:58:52 EDT." <Pine.LNX.4.44.0410201055500.21939-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> On Wed, 20 Oct 2004, Keir Fraser wrote:
> 
> > Yes, so the answer is that we 'flip' about as often as the current
> > code emulates (e.g., about 2.5 million flips/emulations to boot a Red
> > Hat system).
> >
> > The performance is very bad, but the flipping code is both simpler and
> > more robust than emulation so I will go with the new technique.
> 
> How bad is the performance?  A 10% performance penalty, 30% ?

My benchmark is 'time /bin/ls -R /usr/lib >/dev/null' with a warm
buffer cache.

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.

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

> > But I will still print a warning message from Linux to tell the user to
> > remove /lib/tls.
> 
> I've heard that this will actually break some things, like
> db4 locking and the RPM database consistency...

Strange: do the non /lib/tls libraries deal with thread-local state
in some incompatible way?

One fix is to distribute an alternative /lib/tls that is built with
'virtualisation-happy' GS accesses: e.g.,
   mov %%gs:0,%0
   mov <offset>(%0),%1
So we get the same externally-observable semantics (db4 and so on
shouldn't break) but this won't cause Xen to choke.

This may need to be one part of a general move to having two versions
of many executables. GCC now defaults to producing -ve accesses to
thread-local state --- if lots of apps start using the new 'thread'
keyword then this is going to cause problems for Xen unless versions
are built with the approriate GCC command-line switch to produce
virtualisation-happy code (no -ve accesses).

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