Re: [patch] CFS scheduler, -v18

[Ingo Molnar <mingo@elte.hu>]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]


* Mike Galbraith <efault@gmx.de> 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.)

	Ingo

[-- Attachment #2: xterm-spam.c --]
[-- Type: text/plain, Size: 101 bytes --]


#include <time.h>

main ()
{
   while(1)
       printf("%ld\r", 1000 * clock() / CLOCKS_PER_SEC);
}