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
-
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 Jul 31 2003 - 22:00:34 EST