This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 09/14] Add a new pthread_mutexattr_setelision_np interface.
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 3 Jul 2013 09:10:33 +0200
- Subject: Re: [PATCH 09/14] Add a new pthread_mutexattr_setelision_np interface.
- References: <1372452807-25216-1-git-send-email-andi at firstfloor dot org> <1372452807-25216-10-git-send-email-andi at firstfloor dot org> <51D09CA6 dot 7060700 at redhat dot com> <20130630215353 dot GL6123 at two dot firstfloor dot org> <51D20715 dot 7080704 at redhat dot com> <20130702005420 dot GU6123 at two dot firstfloor dot org> <51D302C9 dot 6030002 at redhat dot com>
- Reply-to: libc-alpha at sourceware dot org
On Tue, Jul 02, 2013 at 12:41:45PM -0400, Carlos O'Donell wrote:
> On 07/01/2013 08:54 PM, Andi Kleen wrote:
> > - One scenario that may well happen is that some distributions don't
> > want to force everyone to use elision (and don't trust the adaptive
> > algorithms to be good enough). In this case they likely will not
> > set the configure flag. But individual applications may want
> > to enable elision, because they have lock scaling problem.
> > Now one way would be to use the environment variables (which
> > you also chose not to merge), but then the applications would need to
> > trust that elision works for every lock.
> > With the per lock tuning interface they can instead opt-in
> > only for specific locks, they know have scaling problems and they
> > explicitely tested.
> > I think supporting this model is important (even though I personally
> > prefer elision to be enabled by default).
>
> I agree, but I need to talk this out with the community.
>
> Having a top-down approach to controlling elision per lock
> is important. I have already stated that I think a perfect API and
> implementation that infers elision correctly 100% of the time
> is an unreasonable goal.
> Somewhere, sometime, downstream
> is going to need to disable elision for just one lock, or enable elision
> for just one lock.
I doubt that this is realistic. If an application is harmed by
elision in general or for specific locks, one of three things is
probably going to happen: Either the problem is ignored, or
elision is disabled completely for that application. Or, if the
developers think it would be helpful to use transactions in the
application, it is rewritten so that the work it does benefits
from transactions without relying on elision. The lock elision
concept is too far away from the hardware instructions, and too
elusive as a concept from the point of view of the application
programmer to be a good aread for optimization. The programmer
will probably want to use a transaction interface in the language
rather than relying on library code.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany