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

[Nick Piggin]

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.

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


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