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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
