This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- To: "fweimer at redhat dot com" <fweimer at redhat dot com>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 13 May 2015 10:41:57 +0000
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <5552104C dot 1020806 at redhat dot com>
On Tue, 2015-05-12 at 14:38 +0000, Florian Weimer wrote:
> On 05/12/2015 12:28 PM, Kinsella, Ray wrote:
> > 2. OS builders creating a UP version of glibc targeted for the X1000.
> > The runtime linker then decides which glibc to load based on a HWCAP,
> > in a similar way to how the Xen specific glibc is loaded.
>
> I think the two cases are not really comparable. Back in those days,
> access to thread-local variables was pretty rare and mostly restricted
> to glibc.
> Nowadays, you'd have to recompile a whole distribution to get rid of
> atomics everywhere, and I can't really see any of the major
> distributions doing that.
I understand - not comparable as we were _sure_ the problem with Xen was
localized to glibc, and therefore _sure_ using an optimized version
glibc solved the problem. However as there is locking outside of glibc,
this solution doesn't apply. Only way to be sure it is not used
system-wide is to rebuild the distribution.
I wrote a script to find the usage of the lock prefix system wide on a
standard install 32bit Debian Wheezy System. It turned up 19546 uses of
LOCK with the balance outside of glibc. There were some odd heavy users
of LOCK outside glibc like /usr/bin/aptitude-curses.
ray@debian-install-builder:~$ objdump -S /usr/bin/aptitude-curses |
egrep 'lock\s' | wc -l
4634
ray@debian-install-builder:~$ objdump -S /usr/bin/aptitude-curses |
egrep 'lock\s' | head -n 5
31ce6: f0 0f c1 48 08 lock xadd %ecx,0x8(%eax)
31d24: f0 0f c1 48 08 lock xadd %ecx,0x8(%eax)
31d94: f0 0f c1 48 08 lock xadd %ecx,0x8(%eax)
31dd2: f0 0f c1 48 08 lock xadd %ecx,0x8(%eax)
31e10: f0 0f c1 48 08 lock xadd %ecx,0x8(%eax)