Re: [Pkg-xen-devel] Re: Xen and glibc
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.
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.
> Cheers,
> Aurelien
--Ralph
Reply to: