On Thu, Jul 27, 2006 at 01:00:01AM +0200, Adam Borowski wrote: > On Fri, Apr 21, 2006 at 02:15:16PM +0200, Gabor Gombas wrote: > > IMHO just go ahead with the upload :-) The removal of the other > > optimized flavors due to the conflict with libc6-xen should only cause > > some performance regression when you boot a non-xen kernel, it should > ^^^^^^^^^^^^^^^^^^^^^^ > > not have any effect on usability. > > Is the part about performance regression actually true? I've spent > quite a bit of time trying to find a test case where the difference > could be measureable, and failed.
I think Gabor meant the regression you get when running with a non-xen libc under xen (compared to xen-libc under xen). > I'm not knowledgeable about TLS issues, but it appears that the > slowdown is on the rate on one CPU cycle per some glibc calls -- way > below any reasonable threshold, and certainly not enough to warrant > the extra disk space and confusion. > > So, what about dropping libc6-xen and simply rebuilding libc6-i686 > with -mno-tls-direct-seg-refs? While you seem to be referring to the regression you get when running with a xen-libc on non-xen kernel (bare metal), compared to regular libc (with negative segment trick) on non-xen kernel. The problem with merging libc-xen and libc-686 is that it brings a performance penalty (though tiny) to people who don't care about Xen at all. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
