OK, I agree that things are quite different, but that's
not my point. My point is that we already check for 'other'
things to run and that it's moot to say that the scheduler
shouldn't do other things than selecting which task to run
-- it already does other things.
> > Adding another one for RT tasks won't be a problem, all we
> > have to do is make sure that the highest-priority RT task
> > is up front.
>
> I don't think a BH paradime for RT processes is the right approach.
> A separate run queue is the natural place, IMHO.
But since we don't have dynamic priorities for RT tasks,
we might as well put them on their runqueue in the right
order. That will mean that we don't have to scan a (potential)
RT runqueue, but that we just take the first available RT
process.
If, OTOH, you and other folks think that my idea is not
as efficient after all, an unsorted queue is fine with
me too...
> Can you avoid the division operation? This is particularly painful
> on lesser CPUs. Even a multiplication should be avoided.
Sure, I can get the division out. But I still like the
fact that niced processes show a slower 'recovery' than
non-niced processes. Something like that should be good
for interactive performance and I'd really like to keep
that.
Besides, if we make a separate code path for RT tasks,
shouldn't we be able to add some 'fancy stuff' to the
other path in order to get better interactive performance?
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/