[lkml]   [2003]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] O12.2int for interactivity
Quoting Timothy Miller <>:
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.100 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site