Messages in this thread | | | Date | Tue, 14 Mar 2000 21:10:33 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |