From: Con Kolivas <kernel@kolivas.org>
To: Tim Connors <tconnors+linuxkernel1073186591@astro.swin.edu.au>,
       linux-kernel@vger.kernel.org
Subject: Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!
Date: Sun, 4 Jan 2004 16:58:57 +1100
User-Agent: KMail/1.5.3
References: <Pine.LNX.4.44.0401031439060.24942-100000@coffee.psychology.mcmaster.ca> <200401041242.47410.kernel@kolivas.org> <slrn-0.9.7.4-25573-3125-200401041423-tc@hexane.ssi.swin.edu.au>
In-Reply-To: <slrn-0.9.7.4-25573-3125-200401041423-tc@hexane.ssi.swin.edu.au>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401041658.57796.kernel@kolivas.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1917
Lines: 41

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.

Con

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/