This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 11 Sep 2013 18:02:02 +0200
- Subject: Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- Authentication-results: sourceware.org; auth=none
- References: <20130902075228 dot GA4792 at linux dot vnet dot ibm dot com> <20130902080214 dot GC4997 at linux dot vnet dot ibm dot com> <87k3izdjn8 dot fsf at tassilo dot jf dot intel dot com> <20130903082522 dot GA16924 at linux dot vnet dot ibm dot com> <87a9jtpl2j dot fsf at tassilo dot jf dot intel dot com>
On Tue, 2013-09-03 at 16:00 -0700, Andi Kleen wrote:
> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
>
> > On Mon, Sep 02, 2013 at 01:59:55PM -0700, Andi Kleen wrote:
> >> Testing untested patches is also not a good idea.
> >
> > I know, but at the moment I have no opther option.
> >
> >> If you don't have a TSX system please don't submit TSX patches.
> >
> > Sorry, I cannot comply with that. I need to submit these patches
> > because they address issues that come up with the port for z, and
> > it is much better to discuss the issues when they come up, even if
> > I cannot test them.
>
> Since z transactions and TSX are somewhat different I think it's
> expected that the elision code for both diverges.
While this might eventually be true, it is something that we should
really try to avoid. Andi, you complained about the multiple
arch-specific versions of some of the pthreads code in the past, and
forking the elision code without need would be exactly the same problem.
We should try really hard to keep this generic as much as possible.
Ideally, I'd like both of you to sit down and flesh out the adaptation
in more detail, and look for the commonalities there.
> I don't see that as a
> bad thing -- these are critical fast paths and should be as optimized as
> possible for the specific CPU, just like memcpy and other hot functions.
>
> So feel free to do these changes to the z code alone.
Nack. (Until it's shown that we likely have to do this.)
> >
> > I completely understand that the removed abort is a very useful
> > tool for testing and analyses for Tsx, and if you have an idea how
> > to fix the abort code misinterpretation problem without "breaking"
> > profiling I'd like to hear it (because this discussion is also
> > relevant for the z port).
>
> We reserved some fixed values for abort codes in the optimization guide
> (you can see that as a kind of ABI)
Is this an official "Intel-blessed" document?
Can you post the link?
Who does this apply to?
Who has been made aware of this, or promised to stick to it?
I'm asking these questions because I've stumbled over this "ABI" just
via contributions you made to different projects (eg, HLE here, GCC's
libitm). IMHO, this should be kinda more official to be considered an
ABI...