Re: RFC: Always-on elision with per-process opt-in using tunables.

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2017-05-11 at 11:45 -0400, Carlos O'Donell wrote:
> I am going to propose the following:
> 
> * Always build with elision support.
> 
> * Elision disabled by default at runtime.
> 
> * Use tunables to allow processes to opt-in to transparent elision.
> 
> The benefit is that the elision support doesn't bit-rot, and we keep
> it working, and that distributions can conservatively backport elision
> and allow users to test enablement on a per-process basis.
> 
> The elision is enabled with:
> 
> GLIBC_TUNABLE=glibc.elision.enable=1
> 
> The obvious set of patches are:
> 
> (a) Split out some cleanups in this patch.
> (b) Always build with elision and us tunables to opt-in.
> (c) Extend tunables to allow modification of elision parameters
>     (useful for upcoming rwlock elision re-enablement).
> 
> I'm testing this on x86_64, ppc64le, and s390x.
> 
> Thoughts?

I agree this would be useful.

Enabling elision by default for a specific target should require that we
have confidence that performance with elision is better overall (which
is affected by the default elision tuning parameters, for example).  We
still need to find consensus on what "better overall" means, but I
believe it needs to be some mix of somewhat better performance overall
while not introducing cases in which elision can make things much worse
(so that we balance improvements in average performance against costs
caused by performance regressions (for the project and for users)).