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

[Nick Piggin]

Peter Osterlund wrote:

> Con Kolivas <kernel@xxxxxxxxxxx> writes:
>
>
> > On Sun, 4 Jan 2004 14:32, Tim Connors wrote:
> >
> > > > Not quite. The scheduler retains high priority for X for longer so it's
> > > > no new dynamic adjustment of any sort, just better cpu usage by X (which
> > > > is why it's smoother now at nice 0 than previously).
> > > >
> > > >
> > > > > If either the scheduler or xterm was a bit smarter or
> > > > > used different thresholds, the problem would go away. It would also
> > > > > explain why there are people who cannot reproduce it. Perhaps a
> > > > > somewhat faster or slower system makes the problem go away. Honnestly,
> > > > > it's the first time that I notice that my xterms are jump-scrolling, it
> > > > > was so much fluid anyway.
> > > > Very thorough but not a scheduler problem as far as I'm concerned. Can
> > > > you not disable smooth scrolling and force jump scrolling?
> > > AFAIK the definition of jump scrolling is that if xterm is falling
> > > behind, it jumps. Jump scrolling is enabled by default.
> > >
> > > What this slowness means is that xterm is getting CPU at just the
> > > right moments that it isn't falling behind, so it doesn't jump - which
> > > means X gets all the CPU to redraw, which means your ls/dmesg anything
> > > else that reads from disk[1] doesn't get any CPU.
> > >
> > > Xterm is already functioning as designed - you can't force jump
> > > scrolling to jump more - it is at the mercy of how it gets
> > > scheduled. If there is nothing more in the pipe to draw, it has to
> > > draw.
> > >
> > > These bloody interactive changes to make X more responsive are at the
> > > expense of anything that does *real* work.
> > Harsh words considering it is the timing sensitive nature of xterm that relies 
> > on X running out of steam in the old scheduler design to appear smooth.
>
> 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?


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