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

From: Nick Piggin <piggin@cyberone.com.au>
To: Peter Osterlund <petero2@telia.com>
Cc: Con Kolivas <kernel@kolivas.org>,
	Tim Connors <tconnors+linuxkernel1073186591@astro.swin.edu.au>,
	linux-kernel@vger.kernel.org
Subject: Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!
Date: Tue, 06 Jan 2004 12:37:13 +1100	[thread overview]
Message-ID: <3FFA1149.5030009@cyberone.com.au> (raw)
In-Reply-To: <m2ptdxq3vf.fsf@telia.com>

Peter Osterlund wrote:

>Con Kolivas <kernel@kolivas.org> 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?