Messages in this thread | | | Date | Tue, 8 Jan 2002 14:21:17 +0100 | From | Andrea Arcangeli <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
On Tue, Jan 08, 2002 at 11:55:59AM +0100, Luigi Genoni wrote: > > > On Tue, 8 Jan 2002, Dieter [iso-8859-15] Nützel wrote (passim): > > > Is it possible to decide, now what should go into 2.4.18 (maybe -pre3) -aa or > > -rmap? > [...] > > Maybe preemption? It is disengageable so nobody should be harmed but we get > > the chance for wider testing. > > > > Any comments? > preemption?? this is eventually 2.5 stuff, and should not be integrated
indeed ("eventually" in the italian sense btw, obvious to me, but not for l-k).
I'm not against preemption (I can see the benefits about the mean latency for real time DSP) but the claims about preemption making the kernel faster doesn't make sense to me. more frequent scheduling, overhead of branches in the locks (you've to conditional_schedule after the last preemption lock is released and the cachelines for the per-cpu preemption locks) and the other preemption stuff can only make the kernel slower. Furthmore for multimedia playback any sane kernel out there with lowlatency fixes applied will work as well as a preemption kernel that pays for all the preemption overhead.
About the other claim that as the kernel becomes more granular performance will increase with preemption in kernel, that's obviously wrong as well, it's clearly the other way around. Maybe it was meant "latency will decrease further", that's right, but also performance will decrease if something.
So yes, mean latency will decrease with preemptive kernel, but your CPU is definitely paying something for it.
> into 2.4 stable tree. Of course a backport is possible, when/if it will be > quite well tested and well working on 2.5 > > > >
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |