This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/6] Optimize number of accesses to *adapt_count in lock elision code.
- From: Andi Kleen <andi at firstfloor dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 03 Sep 2013 16:01:45 -0700
- Subject: Re: [PATCH 1/6] Optimize number of accesses to *adapt_count in lock elision code.
- Authentication-results: sourceware.org; auth=none
- References: <20130902075228 dot GA4792 at linux dot vnet dot ibm dot com> <20130902075808 dot GA4997 at linux dot vnet dot ibm dot com> <874na3djaq dot fsf at tassilo dot jf dot intel dot com> <20130903080224 dot GD3368 at linux dot vnet dot ibm dot com>
Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> On Mon, Sep 02, 2013 at 02:07:25PM -0700, Andi Kleen wrote:
>> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
>>
>> > The changes to the original patches before 2.18 led to semantical changes of
>> > the adapt_count argument. In the current code, *adapt_count cannot fall below
>> > zero. When elision is attempted, *adapt_count is always exactly zero. This
>> > fact can be exploited to reduce the number of accesses to *adapt_count and to
>> > simplify updating *adapt_count.
>>
>> First in hardware <= is exactly the same performance as ==
>
> Yes. The patch changes that to "==" because it's clearer to the
> reader that *adapt_count should not fall below 0 (and if it does,
> it's a bug).
I don't see it as a bug, as the access to these fields is racy.
So I was very conservative.
It's better to keep it.
-Andi
--
ak@linux.intel.com -- Speaking for myself only