That's not a particularly clueful comment, Anton. Obviously, any
latency-busting hacks that Andrew does could also be patched into a
-preempt kernel.
What a preemptible kernel can do that a non-preemptible kernel can't is:
reschedule exactly as often as necessary, instead of having lots of extra
schedule points inserted all over the place, firing when *they* think the
time is right, which may well be earlier than necessary.
The preemptible approach is much less of a maintainance headache, since
people don't have to be constantly doing audits to see if something changed,
and going in to fiddle with scheduling points.
Finally, with preemption, rescheduling can be forced with essentially zero
latency in response to an arbitrary interrupt such as IO completion, whereas
the non-preemptive kernel will have to 'coast to a stop'. In other words,
the non-preemptive kernel will have little lags between successive IOs,
whereas the preemptive kernel can submit the next IO immediately. So there
are bound to be loads where the preemptive kernel turns in better latency
*and throughput* than the scheduling point hack.
Mind you, I'm not devaluing Andrew's work, it's good and valuable. However
it's good to be aware of why that approach can't equal the latency-busting
performance of the preemptive approach.
-- Daniel - 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/