Bug#800574: Final analysis for Broadwell
On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> provide for a possible long-term plan to fine-tune the lock-elision
> blacklist (and anything else of that sort).
>
> We would have to (finally) extend x86-64 hwcap to cpuid(1) fully, and
> also at least cpuid(7), which is anything but trivial and a lot of work.
> This is _not_ worth the trouble if it is done just for lock elision
> blacklisting purposes.
>
> However, it would be useful for link-time optimization in libraries
> (e.g. avx2 flavours of something that really benefits from it, etc), so
> it is likely worth pursuing... but only if we get buy-in from upstream.
Why do you believe that hwcap is better for handling that than the
current STT_GNU_IFUNC mechanism?
For me hwcap is clearly superseded by the STT_GNU_IFUNC:
1) With the hwcap mechanism the libraries need to be recompiled multiple
times, increasing build time, but also the disk space on the users
computer.
2) It makes the upgrades more complex (see the nohwcap part of the libc
preinst/postinst).
3) We need to ensure the ABI is the same for all versions of the same
library (this is not the case for upstream glibc between i586 and i686).
4) The fact that the CPU supports a feature doesn't mean it supports it
with good performances. For instance Intel Silvermont supports SSE4.2,
but SSE2/SSSE3 based version of string functions are much faster there.
5) Finally it means that we need to provide a version of the libc for
all combinations. Think on i386, we would need to provide:
- libc6
- libc6-i686
- libc6-i686-tsx
- libc6-xen
- libc6-xen-tsx
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: