This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] A method for forcing IFUNC selector
- From: Paul Pluzhnikov <ppluzhnikov at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Ondrej Bilka <neleai at seznam dot cz>, Brooks Moses <bmoses at google dot com>
- Date: Thu, 6 Nov 2014 14:37:11 -0800
- Subject: Re: [RFC] A method for forcing IFUNC selector
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobMYNLsv6NSmXqwj7j4kCx1XaQU9m0VExFMrtb3SVKpNxg at mail dot gmail dot com> <20141106220528 dot BB51A2C3AC8 at topped-with-meat dot com>
On Thu, Nov 6, 2014 at 2:05 PM, Roland McGrath <email@example.com> wrote:
> Please contribute to benchtests so that they are more representative of a
> variety of workloads.
Extracting these is quite hard.
It's trivial to show a synthetic case where new memcpy is 50% slower than
the old one, but extracting a *real* memcpy trace showing 10% degradation
is hard because the app is multithreaded, and executes billions of memcpy()s.
> I am not very sanguine either about random new environment variables, nor
> about a mechanism that has users picking implementations by internal symbol
In theory there is no difference between theory and practice, but in
practice there is :-)
In theory I may agree with you: it's bad to allow the user to specify
internal memcpy symbol name.
But in practice we need to run real applications, and these show real
We do need to upgrade glibc for unrelated reasons, and we do need to keep
running existing applications, and we can't take a 10% performance hit
on them *now* (as I said, we'll work to remove some of the memcpy()s,
particularly mis-aligned ones).
So, lacking a documented way to override IFUNC selector, I am left with
an undocumented one.
Also note that specifying internal name maybe isn't so bad -- you can
disclaim all warranties for any user who does that, and you can warn if
e.g. internal name no longer exists, or is not available given the CPUID
> As to the basic way in to do any kind of tweak like this, that is the
> long-standing subject of "tunables".
Sorry, I haven't seen that discussion, and don't understand how it would
help me here.
> I'm more positively disposed towards ideas like a mask for cpuid
> feature bits
Setting or clearing CPUID feature bits will potentially switch multiple
IFUNCs which I do *not* want to do. I want to only change one thing (at
least one thing at a time).