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

[Tim Connors]

Con Kolivas <kernel@xxxxxxxxxxx> said on Sun, 4 Jan 2004 12:42:47 +1100:
> On Sun, 4 Jan 2004 10:35, Willy Tarreau wrote:
> > 6) Conclusion
> > =============
> >
> > Under 2.4, xterm uses jump scrolling which it does not use by default under
> > 2.6 if X responds fast enough. The first dirty solution which comes to mind
> > is to renice X to >+10 to slow it a bit so that xterm hits the high water
> > level and jumps.
> >
> > But it's not an effect of the scheduler alone, but a side effect of the
> > scheduler and xterm both trying to automatically adjust their behaviour in
> > a different manner. 
> 
> 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.


[1] Others say that it only affects them first time through - after
something is cached, it goes back to normal speed. For me - it is slow
*all* the time. If I pipe it to cat or tail or something, it is a
*lot* quicker.



-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Beware of Programmers who carry screwdrivers.
-
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/