Re: [Pkg-xen-devel] Re: Xen and glibc
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]
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
Re: Xen and glibc
Bastian Blank a écrit : On Thu, Mar 16, 2006 at 02:41:09PM +0100, Bastian Blank wrote: - 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 Which patch? Can't you read which is written before? Excuse me, this was a little bit rude. The patch is not needed for 2.4. - 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? It is. It defines another hwcap called nosegneg, which is exported via the elf aux sections. Ok, all that information given, I will have a look, but I don't promise anything on the schedule. -- .''`. 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]
Re: Xen and glibc
On Thu, Mar 16, 2006 at 02:41:09PM +0100, Bastian Blank wrote: > > - 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 > > Which patch? Can't you read which is written before? Excuse me, this was a little bit rude. The patch is not needed for 2.4. > > - 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? > > It is. It defines another hwcap called nosegneg, which is exported via the elf aux sections. Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4. signature.asc Description: Digital signature
Re: Xen and glibc
On Thu, Mar 16, 2006 at 02:30:44PM +0100, Aurelien Jarno wrote: > 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. You can also change the default behaviour of gcc as the assumptions that this works is not longer true even with glibc.. The setting have only little impact on the speed. > 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 Which patch? Can't you read which is written before? > - 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? It is. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3 signature.asc Description: Digital signature
Re: Xen and glibc
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? Cheers, 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]
Re: [Pkg-xen-devel] Xen and glibc
On Wed, Mar 15, 2006 at 10:30:47PM +0100, Goswin von Brederlow wrote: > Do you mean the fix is only for i386 or the problem only exists on > i386? Both ;-) Regards, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Xen and glibc
Julien Danjou <[EMAIL PROTECTED]> writes: > Please note that this issue is only available for i386 arch. available? Do you mean the fix is only for i386 or the problem only exists on i386? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Xen and glibc
Hello, 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. [1] http://wiki.xensource.com/xenwiki/XenSpecificGlibc Regards, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
