Re: [RFCv2] Dynamic lock elision support

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

On Thu, 2015-09-03 at 21:51 +0200, OndÅej BÃlka wrote:
> On Thu, Sep 03, 2015 at 10:08:54AM -0500, Steven Munroe wrote:
> > 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.
> > 
> 
> Then adding tunable for that looks like bad idea. If you want to add
> tunable it should be for something where only programmer has data about
> performance.
> 
I did not ask for a tunable for this. I am asking for a enable / disable
control for TLE.

The community via Carlos et al is asking for a larger discussion about
tunables in general.

I was asked to describe the specific issue that I thought justified
expediting this discussion and or staging the implementation. This was
the intent for my reply to Carlos.

We will address the heuristics for our TLE implementation. But there
will always be cases where the customer and the kernel will do
unexpected things. So a top level control to enable/disable TLE is a
first order requirement.