Re: [PATCH] O12.2int for interactivity

[Timothy Miller <miller@techsource.com>]

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)
> 
> What happens if you change the line
>   struct timespec st={10,50000000}; 
> to
>   struct timespec st={0,250000000}; 
> 
> and the line
>     nanosleep(&st, 0); 
> to
>     for (n=0; n<40; n++) nanosleep(&st, 0); 
> 
> 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)


MR.BARNARD: (shouting) What do you want?
MAN: Well I was told outside...
MRB: Don't give me that you snotty-faced heap of parrot droppings!
MAN: What!
MRB: Shut your festering gob you tit! Your type makes me puke! You 
vacuous toffee-nosed malodorous pervert!!
MAN: Look! I came here for an argument.
MRB: (calmly) Oh! I'm sorry, this is abuse!


Or closer to the point:

"For each record player, there is a record which it cannot play."
For more detail, please read this dialog:
http://www.geocities.com/g0del_escher_bach/dialogue4.html



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.


As Linus says, "Perfect" is the enemy of "Good".