Quoting Timothy Miller <miller@techsource.com>:
>
> The interactivity detection algorithm will always be inherently
> imperfect. Given that it is not psychic, it cannot tell in advance
> whether or not a given process is supposed to be interactive, so it must
> GUESS based on its behavior.
>
> Furthermore, for any given scheduler algorithm, it is ALWAYS possible to
> write a program which causes it to misbehave.
>
> This "thud" program is Goedel's theorem for the interactivity scheduler
> (well, that's not exactly right, but you get the idea). It breaks the
> system. If you redesign the scheduler to make "thud" work, then someone
> will write "thud2" (which is what you have just done!) which breaks the
> scheduler. Ad infinitum. It will never end. And in this case,
> optimizing for "thud" is likely also to make some other much more common
> situations WORSE.
>
>
> So, while it MAY be of value to write a few "thud" programs, don't let
> it go too far. The scheduler should optimize for REAL loads -- things
> that people actually DO. You will always be able to break it by
> reverse-engineering it and writing a program which violates its
> expectations. Don't worry about it. You will always be able to break
> it if you try hard enough.
Thank you for your commentary which I agree with. With respect to these
potential issues I have always worked on a fix for where I thought real world
applications might cause these rather than try and fix it for just that program.
It was actually the opposite reason that my patch prevented thud from working;
it is idle tasks that become suddenly cpu hogs that in the real world are
potential starvers, and I made a useful fix for that issue. Thud just happened
to simulate those conditions and I only tested for it after I heard of thud. So
just a (hopefully reassuring) reminder; I'm not making an xmms interactivity
estimator, nor an X estimator, nor a "fix this exploit" one and so on.
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:31 EST