Linus Torvalds wrote:
quoted text
> Nick,
>  call me a worry-wart, but I slept on this, and started worrying..
> 
> On Tue, 26 Jun 2007, Linus Torvalds wrote:
> 
>>So try it with just a byte counter, and test some stupid micro-benchmark 
>>on both a P4 and a Core 2 Duo, and if it's in the noise, maybe we can make 
>>it the normal spinlock sequence just because it isn't noticeably slower.
> 
> 
> So I thought about this a bit more, and I like your sequence counter 
> approach, but it still worried me.
> 
> In the current spinlock code, we have a very simple setup for a 
> successful grab of the spinlock:
> 
> 	CPU#0					CPU#1
...

Yeah, thanks.

quoted text
> Now, I have good reason to believe that all Intel and AMD CPU's have a 
> stricter-than-documented memory ordering, and that your spinlock may 
> actually work perfectly well. But it still worries me. As far as I can 
> tell, there's a theoretical problem with your spinlock implementation.
> 
> So I'd like you to ask around some CPU people, and get people from both 
> Intel and AMD to sign off on your spinlocks as safe. I suspect you already 
> have the required contacts, but if you don't, I can send things off to the 
> appropriate people at least inside Intel.

Haven't made too much progress on this, but I have asked someone@amd who
might be able to at least know the right person to ask :P (might be faster
to ask Andi to ask :))

If you know someone at Intel then that would be appreciated.

It would be nice if it is safe (and can be guaranteed to be safe in future).

However OTOH, the fastpath may be even faster if we do it in a "definitely
safe" way.

That is, do the xaddw against 16-bits with the head in 8 of those and the
tail in the other 8. Then compare the byte registers of the register
returned by xaddw for the test. Although the xaddw is going to be slower
than an xaddb, this way we subsequently avoid the extra load completely,
while avoiding ordering issues.

In the slowpath we would have to have a token locked op in there (like
the current spinlocks do), but this could be taken out iff our inquiries
come back positive.

Anyway, I'll try redoing the patch and getting some numbers.

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