On Thu, 21 Jun 2007, Eric Dumazet wrote:
>
> This reminds me Nick's proposal of 'queued spinlocks' 3 months ago
>
> Maybe this should be re-considered ? (unlock is still a non atomic op,
> so we dont pay the serializing cost twice)
No. The point is simple:
IF YOU NEED THIS, YOU ARE DOING SOMETHING WRONG!
I don't understand why this is even controversial. Especially since we
have a patch for the problem that proves my point: the _proper_ way to fix
things is to just not do the bad thing, instead of trying to allow the bad
behaviour and try to handle it.
Things like queued spinlocks just make excuses for bad code.
We don't do nesting locking either, for exactly the same reason. Are
nesting locks "easier"? Absolutely. They are also almost always a sign of
a *bug*. So making spinlocks and/or mutexes nest by default is just a way
to encourage bad programming!
> extract :
>
> Implement queued spinlocks for i386. This shouldn't increase the size of
> the spinlock structure, while still able to handle 2^16 CPUs.
Umm. i386 spinlocks could and should be *one*byte*.
In fact, I don't even know why they are wasting four bytes right now: the
fact that somebody made them an "int" just wastes memory. All the actual
code uses "decb", so it's not even a question of safety. I wonder why we
have that 32-bit thing and the ugly casts.
Ingo, any memory of that?
(And no, on 32-bit x86, we don't allow more than 128 CPU's. I don't think
such an insane machine has ever existed).
Linus
-
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]
