That's true, but at some point in the future I think the work involved
in making sure all new additional kernel code and all new intra-kernel
interactions are "tuned" becomes larger than going preemptive all the
way down.
Apple had its arguments for cooperative, along the same lines as what
you've mentioned I believe. And while I agree that the kernel is a much
_more_ trusted environment, I think the possibilities easily remain for
abuse given that there are A) more and more people contributing kernel
code every day, and B) countless unspeakably evil modules out there.
And the preempt tunability that has been mentioned sounds like it would
go a long way.
| Andrew's patches give you 1mS worst case latency for normal situations, that
| is below human perception, and below scheduling granularity. In other words
| without the efficiency loss and the debugging problems you can place the
| far enough latency below other effects that it isnt worth attacking any more.
It sounds like the LL patches are easier and less prone to locking
issues with a lot of the benefit. But I can't help but feel that it's
not using the right tool for the job. I think the end result of
stabilizing a preemptive kernel (in 2.5?) is worth the price, IMHO.
-- Ken. brownfld@irridia.com - 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/