Re: [RFC] A method for forcing IFUNC selector

[Paul Pluzhnikov <ppluzhnikov at gmail dot com>]

On Thu, Nov 6, 2014 at 2:05 PM, Roland McGrath <roland@hack.frob.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
> name.

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
slowdowns.

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
feature bits.

> 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).

Thanks,
-- 
Paul Pluzhnikov