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

[Peter Osterlund <petero2@telia.com>]

Nick Piggin <piggin@cyberone.com.au> 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.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340