Re: [patch] sched-2.6.0-test1-G6, interactivity changes

[Mike Galbraith <efault@gmx.de>]

At 09:18 PM 7/27/2003 +0200, Felipe Alfaro Solana wrote:
>On Sun, 2003-07-27 at 15:40, Ingo Molnar wrote:
> > my latest scheduler patchset can be found at:
> >
> >       redhat.com/~mingo/O(1)-scheduler/sched-2.6.0-test1-G6
> >
> > this version takes a shot at more scheduling fairness - i'd be interested
> > how it works out for others.
>
>This -G6 patch is fantastic, even without nicing the X server. I didn't
>even need to tweak any kernel scheduler knob to adjust for maximum
>smoothness on my desktop. Response times are impressive, even under
>heavy load. Great!

Can you try the following please?

This one I just noticed:
1.  start top.
2.  start dd if=/dev/zero | dd of=/dev/null
3.  wiggle a window very briefly.
Here, X becomes extremely jerky, and I think this is due to two 
things.  One, X uses it's sleep_avg very quickly, and expires.  Two, the 
piped dd now is highly interactive due to the ns resolution clock (uhoh).

This one, I've seen before, but it just became easily repeatable:
1.  start top.
2.  start make -j2 bzImage.  minimize window.
3.  start xmms, and enable it's gl visualization.
4.  grab top window and wiggle it until you see/feel X expire.  (don't blink)
         What you should notice:
         1.  your desktop response is now horrible.
         2.  X is sitting at prio 25, and is not getting better as minutes 
pass.
         3.  the gl thread (oink) is suddenly at interactive priority, and 
stays that way.
5.  minimize gl window
         What you should notice:
         1.  your desktop recovers, because..
         2.  X now recovers it's interactive priority, and the gl thread 
becomes non-interactive.
6.  scratch head ;-)

My conclusions:
1.  evil voodoo.  (then a while later..;)
2.  while X is running, but is in the expired array, the wakeups it is 
supposed to be sending to the gl thread are delayed by the amount of cpu 
used by the two cc1's (also at prio 25) it is round-robining with.  Ergo, 
the gl thread receives that quantity of additional boost.  X is not 
sleeping, he's trying to get the cpu, ergo he cannot receive sleep 
boost.  He can't get enough cpu to do his job and go to sleep long enough 
to recharge his sleep_avg.  He stays low priority.  Kobiashi-maru:  X can't 
keep the cpu long enough to catch up.  Either it expires, or it wakes the 
gl thread, is preempted, and _then_ expires, waits for cc1's, wakes gl 
thread (+big boost), gets preempted again... repeat forever, or until you 
reduce X's backlog, by minimizing,  covering or killing the gl thread.

Conclusion accuracy/inaccuracy aside, I'd like to see if anyone else can 
reproduce that second scenario.

         -Mike