[lkml]   [2007]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] CFS scheduler, -v18

* Mike Galbraith <> wrote:

> This doesn't appear to be a CFS problem. I can reproduce the problem
> easily in virgin 2.6.22-rc7 by starting xterm-spam at nice -1 or
> better. As soon as xterm-spam can get enough CPU to keep the xterm
> fully busy, it's game over, the xterm freezes. The more accurate
> fairness of CFS to sleepers just tips the balance quicker. In
> mainline, the xterm has an unfair advantage and maintains it
> indefinitely... until you tip the scales just a wee bit, at which time
> it inverts.

ah. That indeed makes sense. It seems like the xterm doesnt process the
Ctrl-C/Z keypresses _at all_ when it is 'spammed' with output. Normally,
output 'spam' is throttled by the scroll buffer's overhead. But in
Vegard's case, the printout involves a \r carriage return:

printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);

which allows xterm-spam (attached) to easily flood the xterm (without
any scrolling that would act as a throttle) and the xterm to flood Xorg.

I suspect we need the help of an xterm/Xorg expert? (maybe Keith can
give us further pointers? I can reproduce the problem on a T60 with i940
and Core2Duo running Fedora 7 + Xorg 7.1.)


#include <time.h>

main ()
printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);
 \ /
  Last update: 2007-07-03 09:25    [W:0.059 / U:2.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site