You're hitting spot on the idle detection code. Sleep for a second or longer
and this patch makes you get only your static priority. This way if you
suddenly become a cpu hog you cant starve the machine. ie. it works with your
test exactly as I planned it.
> of any load, that leads to quite long response times. With a make -j5
> bzImage running, I frequently saw response times of over a second. In X,
> with a make -j2 bzImage running, opening a new shell takes too long, and X
Yes I was planning on increasing the child penalty to 95 once the other things
settled down. This will speed up start time.
> loses interactive status considerably quicker than stock when doing window
The sleep avg decrements at the same place and at the same rate in my patch as
it does in stock, so I can't see how that's happening.
> wiggle. Init is at 20, and kernel threads bounce around between 15 and 20
> depending on how active they are (doesn't seem good considering they're
> using practically no cpu).
They're idle. Why do they need higher priority?
> Thud is still dead, but maybe _too_ dead ;-) I never saw it get above the
> lowest priority, which is very unfair considering the amount of sleeping it
> does.
It sounds like you're applying your idea of what you expect the priority to be
based on previous algorithms rather than judging it on it's own merits. I
didn't see any mention of whether audio skips less or mouse moves smoother
which is what it's addressing. The data shows it doesn't unfairly
disadvantage other tasks. CPU hogs get treated as such.
Con
-
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/