Linus Torvalds wrote:
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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
