Re: [RFCv2] Dynamic lock elision support

[OndÅej BÃlka <neleai at seznam dot cz>]

On Thu, Sep 03, 2015 at 03:23:15PM -0500, Steven Munroe wrote:
> 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.
> 
But you still didn't answered why its neccessary to manually
enable/disable it, when automatic detection could do job as well. 

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

I am still skeptical of that claim, is it possbible that ellision would
be slow and succeed most of time?

If not then profiling should work. Also this doesn't handle case where
elision helps half mutexes and harms other half where you would need
better granularity than per-program one.
\