Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!

From: Nick Piggin
Date: Tue Jan 06 2004 - 01:29:07 EST




Peter Osterlund wrote:

Nick Piggin <piggin@xxxxxxxxxxxxxxx> writes:


Peter Osterlund wrote:


But the scheduler is also far from fair in this situation. If I run

snip a good analysis...

... but fairness is not about a set of numbers the scheduler gives to
each process, its about the amount of CPU time processes are given.

In this case I don't know if I find it objectionable that X and xterm
are considered interactive and perl considered a CPU hog. What is the
actual problem?


The problem is that if perl would get only slightly more cpu time, it
would get ahead of xterm, which would make this test case run
something like 10 times faster than it currently does. (Because xterm
switches to jump scrolling when it can't keep up.)

I guess it would be possible to fix this by introducing a
usleep(10000) at some strategic place in the xterm source code, but I
still find it strange that two tasks eating 40% cpu time each are
considered interactive, while a task eating 4% is considered a cpu
hog, especially since the 4% task never got a chance to prove that it
didn't want to steal all cpu time. All that was proven was that it
wanted more than 4% of the cpu.

Also, while my test case runs, other tasks (such as running "ps" from
a network login) are very slow, at least until the extra load makes
the scheduler realize that the two tasks eating most of the cpu time
should not have maximum priority bonus.


This is what top looks like with my (now fixed) scheduler
(priorities go from 0 to 59). In theory I guess it looks like what
you want.

920 root 21 -10 88156 17m 79m S 50.8 7.0 11:08.47 XFree86
16762 npiggin 40 0 4804 2396 4356 R 37.9 0.9 0:07.76 xterm
16784 npiggin 23 0 3128 1212 2664 S 9.3 0.5 0:01.93 perl

xterm is a CPU hog, XFree86 is half and half, perl is at close to highest
priority (which is 20 for a nice 0 process). When using xterm without jump
scrolling, it seems to mess up X's scheduler by flooding it with so many
small requests.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/