Re: [RFCv2] Dynamic lock elision support

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Wed, 2015-09-02 at 14:58 -0400, Carlos O'Donell wrote:
> On 08/31/2015 03:24 PM, Paul E. Murphy wrote:
> > Narrowing my focus here, we should have a runtime
> > mechanism to disable elision for those applications
> > which experience significant degradation from the
> > non-optional nature of this feature.
> > 
> > I think we can table the discussion of runtime
> > tunable parameters as it is highly dependent on the
> > framework which emerges.
> > 
> > In the meantime, there is a need to turn this
> > off for select workloads. It would be preferable
> > to add this in such a way that it can be easily
> > merged into the tunables framework when it
> > does evolve.
> 
> Is this theoretical or do you have such customer workloads,
> I'm not talking about the synthetic benchmarks you have, where
> default pthread mutexes cause the application to experience
> significant performance loss?
> 
We are motivated to address this issue as we have code (TLE enabled
GLIBC) in in the field and have heard some complaints. Unfortunately the
customer did not provide a test case.

Our (well Paul's really) analysis is that we are missed tuned for TLE
transactions that abort due to syscalls within the critical region. This
is compounded by older kernels that did not tabort the transaction early
but cause the transaction to fail due to other (like overflowing the
foot print) reasons. Net for some applications (with a propensity to
include syscalls within pthread_mutex critical regions) we see near 100%
TLE abort frequencies. And we are taking an extra long time to abort the
transaction.

Clearly is better to tabort the transaction early for most syscalls but
we do not expect correct handling of this until 4.2 or later.

So for now (until non-TLE friendly kernels age out of the system) a
mechanism to optionally disable TLE seems like a good idea.

> If you are proposing that your patch is sufficiently important
> to bypass the tunables discussion and get accepted right away
> then you need to give sufficient detail for the community to
> accept that we need to move quickly because users are having
> problems.
> 
We are willing to work with the community as long as the discussion does
not drag-on or turn into a filibuster.

We do need to fix this for existing customers, soon.  

> Otherwise I think that Siddhesh's present work should get
> reviewed by you, and others, get merged, and represent the
> basis for an internal tunables API that enables per-env-var
> tunables.
> 
> In summary, we can add "yet one more env var" for you, but
> you have to justify it.
> 
> Cheers,
> Carlos.
>