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: Rich Felker <dalias at aerifal dot cx>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: f at two dot firstfloor dot org, Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 13 Jun 2013 19:41:53 -0400
- 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>
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.
And the important part to me, covered in the thread about environment
variables, is that no env var should be able to make the
implementation non-conforming or otherwise break existing, working
programs, especially if the env var is honored for suid programs.
Rich