[Pkg-xen-devel] Re: Xen and glibc

[Aurelien Jarno]

Hi!

On Thu, Mar 16, 2006 at 02:59:43PM +0100, Ralph Passgang wrote:
> Am Donnerstag, 16. März 2006 14:30 schrieb Aurelien Jarno:
> > Julien Danjou a écrit :
> > > Hello,
> >
> > Hi!
> >
> > > We [the Debian Xen package team] are currently working on Xen packages,
> > > and are planning to include them into Debian.
> > >
> > > A current issue in Xen, is the libc problem.
> > >
> > > From the Xen wiki [1]:
> > > "Xen uses segmentation to provide protection of the memory used for the
> > > hypervisor. This results in some performance issues since wrap-around
> > > segments as used by glibc need expensive extra handling. [...]
> > >
> > > It is possible to rebuild glibc so that it only uses segments such that
> > > there is no performance penalty. To do this, you need to apply the patch
> > > below to the glibc sources and then rebuild glibc with the
> > > -mno-tls-direct-seg-refs option."
> > >
> > > Currently, we expect our users to move /lib/tls away (or to create
> > > /etc/ld.so.hwnocap, thanks to aurel32 for the tips).
> > > You will understand that this is not very convenient, and will disable
> > > more stuff than really needed.
> > >
> > > Would it possible to add an extra flavor to the current glibc with the
> > > correct build options ?
> > >
> > > Please note that this issue is only available for i386 arch.
> >
> > As already said on IRC, my main concern is that if we accept that, it
> > will be more difficult to refuse some more flavors. I don't want to end
> > up with 10 flavors of the glibc. If we stop to Xen, that's ok for me.
> >
> > On the technical points::
> > - The patch is not conditional, and it is currently not possible to use
> > different sources for different flavors. But as it is fixed in glibc
> > 2.4, it should be possible to backport the fixes.
> > - How we detect to use this flavor and not the tls or the default one?
> > Is there any flag exported by the kernel? How is it done on other
> > distributions?
> 
> If a xenified Kernel is running the "directory" /proc/xen with some 
> subdirs/files exist. Bastian is more familiar with this and already posted 
> more information on this. 

You can't rely on a /proc directory for that. It is not guaranteed it
is mounted at any time, and also it's not really a good idea to check
/proc/xen at every dynamic linker call.

> I am not sure how other distributions handles this situation, but as far as I 
> see comments on the xen mailinglist/wiki/... it's not handled on other 
> distibutions at all for now. Xen is getting a lot of attention right now and 
> that because it's really a great technique, but it's not integrated very well 
> in distributions because xen3 is quite new (released at the end of last 
> year).
> 
> There are some inofficial glibc packages for suse, fedora & of course debian, 
> but I guess the most users simply move /lib/tls to /lib/tls.disable (as 
> mentioned in the xen documentation). But even if I am not familiar enough 
> with this stuff to really know how much performance this costs, providing a 
> special glibc for xen has even more advantages than just more speed. It's a 
> solid solution even for glibc upgrades and can be used for all running guest 
> systems.
> 
> Btw. if I am not totally wrong, this should also help UML (user-mode-linux), 
> because there it's also needed to move /lib/tls away or using a "special" 
> glibc version (I guess for the same reason). So if I am getting this correct, 
> this could be a glibc flavour for all/many virtualisation techniques and not 
> just for xen.

The problem with that, is that the corresponding kernel should export
an hwcap flag via the elf aux sections. Does the UML kernel does that?

And again, I don't want to see a lot of flavours for every
virtualization system in the glibc.

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32 at debian.org         | aurelien at aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net