On Tue, 14 Mar 2000, Roman Zippel wrote:
> > 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.
>
> Only i386, arm and sh need to look up current and on all other
> architectures it's almost free. I would say, why not experimenting with
> and keep as an option, you don't want that on servers of course, where
> throughput is far more important, but if want to play qua^H^H^Hmp3s...
I don't think people understand.
I WILL NOT APPLY THE PATCHES I'VE SEEN SO FAR.
They suck. Sorry, Ingo.
They add new infrastructure to do something that the SMP code has been
doing for ages. I consider them ugly. They buy you nothing that wouldn't
be cleanly done by my simple suggestion, and my simple suggestion gets it
right in GENERAL, not in the few special cases that Ingo's code handled.
There are absolutely no advantages to doing it the stupid way. So why do
it that way, then?
Using the existing spin_lock()/lock_kernel() infrastructure means that
- the locks get verified on UP, and it makes peopleaware of what the cost
of lock_kernel() is on both UP =and= SMP. Imagine extending the current
profiling code trivially to show very clearly where interrupts happen
during active spinlocks - it would be very efficient at pinpointing
code that runs under lock_kernel and causes latency degradation.
- the UP kernel is threaded in all the same places the SMP kernel is
threaded, not just in a few special cases.
- you do not introduce any new forms of threading.
And it's fast and simple. What more can you ask for? Most of the spinlocks
are already of the irqsaving kind which would be complete no-ops in my
version of the threading code.
In contrast, the other approaches have either made spinlocks slower on
SMP, or have added special cases around special code. Ingo's patch is
simple, but would not show how the latency of filename lookup is still
going to be noticeable. But eventually we'll have a fully threaded dcache,
and issues like that go away on their own if just designed right.
I do not like the notion of introducing new concepts that aren't really
even needed as far as I can tell.
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:27 EST