linux-kernel - Re: [patch] CFS scheduler, -v18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070703083133.GC13149@elte.hu>
Date:	Tue, 3 Jul 2007 10:31:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Keith Packard <keith.packard@...el.com>
Cc:	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


* Keith Packard <keith.packard@...el.com> wrote:

> 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.

ah. Thanks for the explanation!

> You can 'fix' xterm with:
> 
> $ xterm -xrm '*minBufSize: 4095'

indeed, that solves the xterm-spam Ctrl-C/Ctrl-Z problem here!

> 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.

yeah, i use gnome-terminal exclusively. But testers looking for CFS 
regressions do run every shell on the planet :-)

gnome-terminal is also faster all around (at least on my box):

 $ (echo '#!/bin/bash' ; echo 'for ((i=0; i<100000; i++)); do echo $i; done') > 1.sh; chmod +x 1.sh; time xterm $HOME/1.sh; time gnome-terminal  -x ./1.sh

 real    0m3.193s
 user    0m2.840s
 sys     0m0.460s

 real    0m2.495s
 user    0m2.430s
 sys     0m1.520s

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