On Tue, 5 Aug 2003 05:50, Charlie Baylis wrote:
> > I tried them aggressively; irman2 and thud don't hurt here. The idle
> > detection limits both of them from gaining too much sleep_avg while
> > waiting around and they dont get better dynamic priority than 17.
>
> Sounds like you've taken the teeth out of the thud program :) The original
> aim was to demonstrate what happens when a maximally interactive task
> suddenly becomes a CPU hog - similar to a web browser starting to render
> and causing intense X activity in the process. Stopping thud getting
> maximum priority is addressing the symptom, not the cause. (That's not to
> say the idle detection is a bad idea - but it's not the complete answer)
It was a side effect that it helped this particular issue. The idle detection
was based around helping real world scenarios and it just happened to help.
> the idea is to do a little bit of work so that the idle detection doesn't
> kick in and thud can reach the max interactive bonus. (I haven't tried your
> patch yet to see if this change achieves this)
Good call; I was quite aware this is the most effective way to create a fork
bomb with my patch, but it's effect while being noticably worse than the
original thud is still not disastrous. Yes I do appreciate variations on the
theme can be made worse again; I'm doing some testing and experimenting there
to see how best to tackle it.
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/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:26 EST