Re: interactive task starvation

[Lee Revell <rlrevell@joe-job.com>]

On Tue, 2006-03-21 at 15:52 +0100, Ingo Molnar wrote:
> * Willy Tarreau <willy@w.ods.org> wrote:
> 
> > Ah no, I never use those montruous environments ! xterm is already 
> > heavy. [...]
> 
> [ offtopic note: gnome-terminal developers claim some massive speedups
>   in Gnome 2.14, and my experiments on Fedora rawhide seem to 
>   corraborate that - gnome-term is now faster (for me) than xterm. ]
> 
> > [...] don't you remember, we found that doing "ls" in an xterm was 
> > waking the xterm process for every single line, which in turn woke the 
> > X server for a one-line scroll, while adding the "|cat" acted like a 
> > buffer with batched scrolls. Newer xterms have been improved to 
> > trigger jump scroll earlier and don't exhibit this behaviour even on 
> > non-patched kernels. However, sshd still shows the same problem IMHO.
> 
> yeah. The "|cat" changes the workload, which gets rated by the scheduler 
> differently. Such artifacts are inevitable once interactivity heuristics 
> are strong enough to significantly distort the equal sharing of CPU 
> time.

Can you explain why terminal output ping-pongs back and forth between
taking a certain amount of time, and approximately 10x longer?  For
example here's the result of "time dmesg" 6 times in an xterm with a
constant background workload:

real    0m0.086s
user    0m0.005s
sys     0m0.012s

real    0m0.078s
user    0m0.008s
sys     0m0.009s

real    0m0.082s
user    0m0.004s
sys     0m0.013s

real    0m0.084s
user    0m0.005s
sys     0m0.011s

real    0m0.751s
user    0m0.006s
sys     0m0.017s

real    0m0.749s
user    0m0.005s
sys     0m0.017s

Why does it ping-pong between taking ~0.08s and ~0.75s like that?  The
behavior is completely reproducible.

Lee