On Tue, 14 Mar 2000, Linus Torvalds wrote:
> 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.
ok, i understand. What i find inconsistent is the way we 'punish' the SMP
kernel with this method. A dual-CPU system would be worse at handling
latencies than a UP kernel. Yes, two CPUs are less likely to be in a
latency-critical section at once, but under certain (typical) workloads
it's going to be pretty often - and nobody is going to care because most
people will have the nicely preemptable UP kernel. The latency-quality of
the SMP kernel will be much worse than the UP kernel's latency.
our SMP spinlocks are very short and localized now in 90% of the cases,
basically only maybe some of the filesystem code and fork() is within the
big kernel lock. But we still do execute in kernel-space without hitting a
preemption point for many millisecs, and on SMP with lots of RAM the
probability of having such code paths increases. I just find it hard to
accept such wildly different characteristics - SMP should be _better_ at
handling latencies, not worse. Should i boot an UP kernel if i want to
listen music at an acceptable quality and still sometimes do serious work?
It just takes one skip per minute under normal workload (or during kernel
compiles, or whatever non-idle situation) and users quickly think the OS
sucks multimedia-wise.
i do see the advantage as well: testing on UP automatically tests some
(most) of the SMP characteristics as well.
i also accept the fact that UP and SMP _are_ different, and we should not
be surprised if the architecture diverges over time. I just did not
anticipate such a direction :-)
Ingo
-
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:29 EST