This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 08/14] Add manual for lock elision
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Andi Kleen <ak at linux dot jf dot intel dot com>, libc-alpha at sourceware dot org
- Date: Fri, 28 Jun 2013 15:06:35 -0400
- Subject: Re: [PATCH 08/14] Add manual for lock elision
- References: <1372398717-16530-1-git-send-email-andi at firstfloor dot org> <1372398717-16530-9-git-send-email-andi at firstfloor dot org> <51CD44B5 dot 5000202 at redhat dot com> <20130628145037 dot GU6123 at two dot firstfloor dot org> <51CDC3FF dot 9050101 at redhat dot com> <20130628172137 dot GY6123 at two dot firstfloor dot org> <51CDC90A dot 6040706 at redhat dot com> <20130628174208 dot GX5643 at tassilo dot jf dot intel dot com> <51CDCF79 dot 902 at redhat dot com> <51CDD0E1 dot 5030006 at redhat dot com> <20130628183935 dot GZ6123 at two dot firstfloor dot org>
On 06/28/2013 02:39 PM, Andi Kleen wrote:
> On Fri, Jun 28, 2013 at 02:07:29PM -0400, Carlos O'Donell wrote:
>> On 06/28/2013 02:01 PM, Carlos O'Donell wrote:
>>> On 06/28/2013 01:42 PM, Andi Kleen wrote:
>>>>> If it's temporary then you shouldn't mind if we checkin
>>>>> a temporary manual patch that ensures we have something
>>>>> in place for 2.18?
>>>>
>>>> Are you saying you want to ship 2.18 without the tuning
>>>> interfaces?
>>>
>>> No. I'm saying that all commits to master should be
>>> transiently correct at all times.
>>
>> For avoidance of doubt I expect a single commit to add
>> all of the baseline elision work to glibc.
>
> The patches were designed to be bisectable, so there
> should be no real reason to not keep my ordering.
While you might have designed the first few patches
to be bisectable, I've indicated in several places where
there are dependencies between the first 9 patches.
Thus I'd like to see them go in as one commit that adds
baseline elision support.
We also have to allow for downstream's that choose to
entirely remove elision, which would be a valid thing
to do.
>> That way if someone cherry-picks just that commit they
>> get a sensible set of patches and a sensible manual.
>
> I don't think the interface-less variant is particularly
> useful on its own, so I hope noone is doing that.
I don't want to judge what downstream does or does not want
to do, those are their own choices to make.
> AFAIK all the previous objections to the in program
> tuning interfaces have been addressed anyways,
> so they should be mergeable for 2.18.
We'll get to reviewing that ASAP.
Cheers,
Carlos.