[Pkg-xen-devel] Re: Xen and glibc
aurelien at aurel32.net
Sat Mar 18 14:44:14 UTC 2006
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 :
> > > "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
> 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
> 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.
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32 at debian.org | aurelien at aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
More information about the Pkg-xen-devel