Re: [PATCH RFC 0/7] x86: convert ticketlocks to C and remove duplicatecode

[H. Peter Anvin]

On 06/22/2011 01:59 PM, Jeremy Fitzhardinge wrote:
> On 06/22/2011 01:19 PM, H. Peter Anvin wrote:
>> On 06/22/2011 12:21 PM, Jeremy Fitzhardinge wrote:
>>> A friend just pointed out that gcc has a "__sync_fetch_and_add()"
>>> intrinsic, which compiles to xadd when used in this context.  What's the
>>> general feeling about using these kinds of gcc features?
>>>
>> In general they are good, IF:
>>
>> a) they cover all versions of gcc we care about (or we have a fallback),
> 
> What is the supported range for these days?
> 

For x86, we support 3.4, 4.0 and 4.1.2 and above (not sure if 4.0.x
actually works).  Other architectures have different rules.  At some
point we'll probably drop anything below 4.1.2, but we apparently can't yet.

>> and
>> b) they have the right semantics.
> 
> My main concern was making sure that its a strong enough barrier, but
> the documentation is pretty explicit about that.
> 
>> Using gcc intrinsics can generate better code than we can in inline
>> assembly.
> 
> It does seem to do a pretty good job; it generates a plain locked add if
> you never look at the returned value, for example.
> 
>> However, (b) is a killer since gcc doesn't have a way to generate our
>> lock prefix annotations, and so it isn't really useful here.
> 
> Yeah, I thought about that.  Its a bit unfortunate we're getting into
> spinlock code at all on a UP system, but we don't have a mechanism to
> stomp locking at a higher level.  (Ignoring all the insane stuff that
> happens when the system becomes UP transiently just because all the
> other CPUs have been unplugged for suspend, etc; we just shouldn't
> bother in that case.)

Yep...

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/