On Thu, 2001-09-20 at 19:15, Andrea Arcangeli wrote:
> All I'm saying is that you should check for >= 0, not == 0.
And I am saying we already keep track of that, we have a preemption
counter.
> But anwyays it's pretty depressing to see such a costly check needed to
> get latency right with the preemptive kernel approch, with
> non-preemptive kernel we'd need to just check need_resched and a call
> schedule in the unlikely case so it would be even lighter :) and no
> fixed costs in UP spinlocks, per-cpu datastrctures etc... The point of
> preemptive kernel would be just to prevent us to put such kind of
> explicit (costly) checks in the code. My theory was that the cpu-costly
> loops are mostly protected by some lock anyways and the fact you're
> writing such horrid (but helpful) code is a kind of proof.
Well, with the preemptive kernel we already account for 90% of the high
latency areas.
Doing the "horrid" solution may solve some other issues, but agreeably
you are right its not the prettiest solution.
I don't agree, however, that its that much more costly, and maybe I am
missing something. Assuming we are SMP (and thus have locks), where is
there a lot more overhead? We check current->need_resched (which we
dont _have_ to), call unlock_kernel() and then call lock_kernel(), with
preemption happening automatically in between. The preemption code
merely checks a counter and calls preempt_schedule() if needed.
Now, yes, this is not ideal. Ideally we don't need any of this muck.
Ideally preemption provides everything we need. So, towards the future,
we can work towards that. For very short locks, we could just disable
interrupts (a lot less overhead). For long-held locks, we can replace
them with a more efficient lock -- spin-then-sleep or a
priority-inheriting mutex lock, for example.
I don't want to confuse the above, which is perhaps an ideal system for
inclusion in 2.5, with trying to lower latency further for those who
care via conditional scheduling and the such.
We already have average latency of <1ms with peaks 10-50ms.
-- Robert M. Love rml at ufl.edu rml at tech9.net- 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/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:41 EST