On Mon, 13 Mar 2000, Ingo Molnar wrote:
> > NOTE NOTE NOTE! You must NOT change the SMP case at all, including the
> > "are we in the kernel" test. Not only do we not have a global
> > spinlock_count (and we don't want one - it would be cache-line death),
> > but even if we used the above heuristic it would be seriously wrong on
> > SMP, because it would mean that anything that caches the value of
> > "current CPU" would need to lock. Which is just too expensive to even
> > think about, because it happens all over the place. On UP, that just
> > isn't a problem ;)
>
> oops, i missed that indeed, darn. Hm., there are not all that many such
> places though, and the value itself is cached in current->processor anyway
> (and 'current' can be cached across reschedules). I cannot see any easy
> way to avoid this bug in any 'automatic' way though. How can we prevent
> writing a 'semi-constant' to a local variable, possibly at compile-time?
Solution: don't do it, then.
There is pretty much no point in making the SMP case be "threaded" in
this sense.
Threaded kernels are WAAAY overvalued. I did not agree with the
low-latency patches because I thought they were ugly for no real gain. I
_would_ agree to the UP-case only thing, simply because it uses the SMP
locking that already exists, and extends it in a simple way to the UP case
("threading" a UP box by making the scheduling consider one CPU as a
special case of multiple CPU's).
Threading the SMP case is simply not worth it. With two CPU's you already
get the benefit of threading across CPU's instead of across "time", to the
degree that the small added advantage of anything else is not worth it.
Really.
Don't even try to thread the SMP case. I wouldn't accept the patches
anyway.
Also, don't try to be clever about the UP case. I would not accept patches
that do what you suggested
thread_avoid();
__spin_lock(x);
__spin_lock(y);
...
__spin_unlock(y);
__spin_unlock(x);
thread_unavoid();
because that defeats the whole process of using the SMP locking for the UP
case, and that's a slippery slope. Soon enough people will start trying to
be clever, and that's just too horrible to contemplate.
Getting nested locks is expensive. If people are aware of that expense
even on UP, all the better. Don't fight it.
> hm, current->spinlock_depth should work pretty well i believe, no? That
> one is SMP-safe as well. It doesnt have any global cacheline problems
> either.
Agreed, but what is the point of it? Now every spinlock has to look up
current. The nice spinlock code that used to be 2 instructions (or 1 for
the unlock case) suddenly became 5 or more. No, thank you. Especially as I
don't believe it buys you anything on SMP.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:25 EST