This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TSX lock elision for glibc v10
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 14 Jun 2013 10:39:54 +0200
- Subject: Re: TSX lock elision for glibc v10
- References: <1370969416-8337-1-git-send-email-andi at firstfloor dot org> <1371140799 dot 16968 dot 19087 dot camel at triegel dot csb> <20130613193514 dot GE29800 at brightrain dot aerifal dot cx> <20130613200843 dot GM6123 at two dot firstfloor dot org> <20130613205352 dot GF29800 at brightrain dot aerifal dot cx> <20130613210753 dot GO6123 at two dot firstfloor dot org>
- Reply-to: vogt at linux dot vnet dot ibm dot com
On Thu, Jun 13, 2013 at 11:07:53PM +0200, Andi Kleen wrote:
> > > Only requiring opt-in would kill a lot of the benefits from
> > > putting this into glibc. Disabling any nesting would also kill a lot of the
> > > benefit.
> >
> > Adding a separate constant for NORMAL type mutexes would fix the issue
> > completely and could be done right now without any controversy.
>
> But old executables don't know anything about new constants.
> They just use "0". Such a change would only affect rebuilt programs.
>
> The important part for me is also that default is able to elide.
I don't think a feature that has the potential to cut performance
in half in certain corner cases should be enabled by default
without thorough field testing.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany