Bug#363442: libc6-xen should not conflict with any other libc6-$flavor
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
Marcin Owsiany <firstname.lastname@example.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216