On Fri, 1 Aug 2003, Con Kolivas wrote:
> > Does this help interactivity a lot, or was it just an experiment?
> > Perhaps it could be less agressive or something?
>
> Well basically this is a side effect of selecting out the correct cpu hogs in
> the interactivity estimator. It seems to be working ;-) The more cpu hogs
> they are the lower dynamic priority (higher number) they get, and the more
> likely they are to be removed from the active array if they use up their full
> timeslice. The scheduler in it's current form costs more to resurrect things
> from the expired array and restart them, and the cpu hogs will have to wait
> till other less cpu hogging tasks run.
If that's what it really does, fine. I'm not sure it really finds hogs,
though, or rather "finds only true hogs."
>
> How do we get around this? I'll be brave here and say I'm not sure we need to,
> as cpu hogs have a knack of slowing things down for everyone, and it is best
> not just for interactivity for this to happen, but for fairness.
While this does a good job I'm still worried that we don't have a good
handle on which processes are realy interactive in term of interfacing
with a human. I don't think we can make the scheduler do the right thing
in every case unless it has better information.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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 : Thu Jul 31 2003 - 22:00:50 EST