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: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.


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...


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