This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFCv2] Dynamic lock elision support
- From: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Steve Munroe <sjmunroe at us dot ibm dot com>, stli at linux dot vnet dot ibm dot com, Siddhesh Poyarekar <siddhesh at redhat dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Tue, 8 Sep 2015 11:30:17 -0500
- Subject: Re: [RFCv2] Dynamic lock elision support
- Authentication-results: sourceware.org; auth=none
- References: <55D358D8 dot 7020303 at linux dot vnet dot ibm dot com> <55D3615F dot 1020300 at linaro dot org> <55E4A9E7 dot 3030700 at linux dot vnet dot ibm dot com> <55E746D2 dot 7070309 at redhat dot com> <1441292934 dot 5575 dot 18 dot camel at oc7878010663> <20150903195159 dot GA18854 at domone> <1441311795 dot 5575 dot 31 dot camel at oc7878010663> <20150905062321 dot GA16169 at domone>
On 09/05/2015 01:23 AM, OndÅej BÃlka wrote:
> 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:
>>>
>>> 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.
>
OndÅej, you do present an interesting idea. I appreciate your feedback,
but we are still a few steps prior to tuning TLE in such a way. I think
we need to take a conservative approach with TLE, especially on PPC,
as we work out the kinks.
TLE is much more sensitive on PPC than other architectures. Having too
many users ruins it for all. The hardware works best with very short
critical sections, or low contention for TLE resources per thread/core.
Mixing in with the tunables discussion, we will be retaining the right
to remove, or alter these options as we see fit. Such a change can be
trivially reverted should we find an effective runtime heuristic, but
we lack the breadth of data to propose a good mechanism in the
meantime.
BR,
Paul