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

[Nick Piggin <piggin@cyberone.com.au>]

Peter Osterlund wrote:

>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.
>

OK yeah you are right. I perl should get more CPU time if it wants it.