linux-kernel - Re: RSDL v0.31

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]

Date:	Tue, 20 Mar 2007 13:31:06 +0100
From:	Artur Skawina <art_k@...pl>
To:	Xavier Bestel <xavier.bestel@...e.fr>
CC:	Willy Tarreau <w@....eu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mark Lord <lkml@....ca>, Al Boldi <a1426z@...ab.com>,
	Mike Galbraith <efault@....de>,
	Con Kolivas <kernel@...ivas.org>, ck@....kolivas.org,
	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Nicholas Miell <nmiell@...cast.net>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RSDL v0.31

Xavier Bestel wrote:
> On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
>> I don't agree with starting to renice X to get something usable
> 
> X looks very special to me: it's a big userspace driver, the primary
> task handling user interaction on the desktop, and on some OS the part
> responsible for moving the mouse pointer and interacting with windows is
> even implemented as an interrupt handler, and that for sure provides for
> smooth user experience even on very low-end hardware. Why not compensate
> for X design by prioritizing it a bit ?
> If RSDL + reniced X makes for a better desktop than sotck kernel + X, on
> all kind of workloads, it's good to know.

No, running X at a different priority than its clients is not really
a good idea. If it isn't immediately obvious why try something like
this:

mkdir /tmp/tempdir
cd /tmp/tempdir
for i in `seq -w 1 10000` ; do touch
longfilenamexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx$i
; done
nice --20 xterm &
xterm &
nice -20 xterm &

then do "time ls -l ." in each xterm.

This is what i get on UP 2.6.20+RSDL.31 w/ X at nice 0:
-20: 0m0.244s user   0m0.156s system   0m3.113s elapsed   12.84% CPU
  0: 0m0.216s user   0m0.168s system   0m2.801s elapsed   13.70% CPU
 19: 0m0.188s user   0m0.196s system   0m3.268s elapsed   11.75% CPU

I just made this simple example up and it doesn't show the problem
too well, but you can already see the ~10% performance drop. It's
actually worse in practice, because for some apps the increased
amount of rendering is clearly visible; text areas scroll
line-by-line, content is incrementally redrawn several times etc.
This happens because an X server running at a higher priority than a
client will often get scheduled immediately after some x11 traffic
arrives; when the process priorities are equal usually the client
gets a chance to supply some more data. IOW by renicing the server
you make X almost synchronous.

This isn't specific to RSDL - it happens w/ any cpu scheduler; and
while the effects of less extreme prio differences (ie -5 instead of
-20 etc) may be less visible i also doubt they will help much.

A better approach to X interactivity might be allowing the server to
use (part of) the clients timeslice, but it's not trivial -- you'd
only want to do that when the client is waiting for a reply and you
almost never want to preempt the client just because the server
received some data.

As to RSDL - it seems to work great for desktop use and feels better
than mainline. However top output under 100% load (eg kernel
compilation) looks like below -- the %CPU error seems a bit high...

Tasks:  97 total,   6 running,  91 sleeping,   0 stopped,   0 zombie
Cpu(s): 81.7% us, 18.3% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,
 0.0% si
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

 7566 root      17   0  9196 4108 1188 R  3.0  0.8   0:00.09 cc1

 7499 root      11   0  1952  924  648 S  0.3  0.2   0:00.01 make

12279 root       1   0  5556 2928 2064 S  0.3  0.6   0:00.83 xterm

31510 root       1   0  2152 1100  840 R  0.3  0.2   0:00.25 top

    1 root       1   0  1584   88   60 S  0.0  0.0   0:00.30 init

artur
-
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/