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]