Messages in this thread | | | Subject | Re: interactive task starvation | From | Lee Revell <> | Date | Tue, 28 Mar 2006 22:01:17 -0500 |
| |
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
- 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/
| |