[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1183450089.29867.36.camel@neko.keithp.com>
Date: Tue, 03 Jul 2007 01:08:09 -0700
From: Keith Packard <keith.packard@...el.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: keith.packard@...el.com, Mike Galbraith <efault@....de>,
Vegard Nossum <vegard.nossum@...il.com>,
Dmitry Adamushko <dmitry.adamushko@...il.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] CFS scheduler, -v18
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
> which allows xterm-spam (attached) to easily flood the xterm (without
> any scrolling that would act as a throttle) and the xterm to flood Xorg.
It's just an Xterm bug.
Xterm will look for X input if it ever manages to fill the input buffer
past 32768 bytes. If it manages to get more than 4096 bytes in one read,
it will invoke sched_yield. and then check for input. Gotta love that
sched_yield call.
As it always processes all of the incoming data before trying to read
again, there doesn't appear to be any way it can ever have more than
32768 characters in the buffer.
And, as the kernel will not buffer more than 4095 bytes from a pty,
there isn't any way it will ever read 4096 bytes.
So, it sits there carefully reading every byte from the pty and painting
them on the screen.
You can 'fix' xterm with:
$ xterm -xrm '*minBufSize: 4095'
I hesitate to even suggest a patch to xterm that would solve this
problem correctly. Note that xterm has kludges in several of the output
processing steps which explicitly look for input (most vertical cursor
motion, it seems), which is why any application which scrolls doesn't
cause this problem.
Do you need more reasons to switch to another terminal emulator?
gnome-terminal has finally gotten reasonable; I expect rxvt or konsole
would work just as well.
--
keith.packard@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists