This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFCv2] Dynamic lock elision support



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]