linux-kernel - Re: [REPORT] cfs-v4 vs sd-0.44

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, 24 Apr 2007 16:21:28 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Nick Piggin <npiggin@...e.de>,
	Juliusz Chroboczek <jch@....jussieu.fr>,
	Con Kolivas <kernel@...ivas.org>, ck list <ck@....kolivas.org>,
	Bill Davidsen <davidsen@....com>, Willy Tarreau <w@....eu>,
	William Lee Irwin III <wli@...omorphy.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Galbraith <efault@....de>,
	Thomas Gleixner <tglx@...utronix.de>, caglar@...dus.org.tr,
	Gene Heskett <gene.heskett@...il.com>
Subject: Re: [REPORT] cfs-v4 vs sd-0.44

Arjan van de Ven wrote:
>> Within reason, it's not the number of clients that X has that causes its 
>> CPU bandwidth use to sky rocket and cause problems.  It's more to to 
>> with what type of clients they are.  Most GUIs (even ones that are 
>> constantly updating visual data (e.g. gkrellm -- I can open quite a 
>> large number of these without increasing X's CPU usage very much)) cause 
>> very little load on the X server.  The exceptions to this are the 
> 
> 
> there is actually 2 and not just 1 "X server", and they are VERY VERY
> different in behavior.
> 
> Case 1: Accelerated driver
> 
> If X talks to a decent enough card it supports will with acceleration,
> it will be very rare for X itself to spend any kind of significant
> amount of CPU time, all the really heavy stuff is done in hardware, and
> asynchronously at that. A bit of batching will greatly improve system
> performance in this case.
> 
> Case 2: Unaccelerated VESA
> 
> Some drivers in X, especially the VESA and NV drivers (which are quite
> common, vesa is used on all hardware without a special driver nowadays),
> have no or not enough acceleration to matter for modern desktops. This
> means the CPU is doing all the heavy lifting, in the X program. In this
> case even a simple "move the window a bit" becomes quite a bit of a CPU
> hog already.

Mine's a:

SiS 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display adapter according 
to X's display settings tool.  Which category does that fall into?

It's not a special adapter and is just the one that came with the 
motherboard. It doesn't use much CPU unless I grab a window and wiggle 
it all over the screen or do something like "ls -lR /" in an xterm.

> 
> The cases are fundamentally different in behavior, because in the first
> case, X hardly consumes the time it would get in any scheme, while in
> the second case X really is CPU bound and will happily consume any CPU
> time it can get.

Which still doesn't justify an elaborate "points" sharing scheme. 
Whichever way you look at that that's just another way of giving X more 
CPU bandwidth and there are simpler ways to give X more CPU if it needs 
it.  However, I think there's something seriously wrong if it needs the 
-19 nice that I've heard mentioned.  You might as well just run it as a 
real time process.

Peter
-- 
Peter Williams                                   pwil3058@...pond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce
-
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/