| 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
| ||
|
Message-ID: <20070423024245.GA8378@elte.hu> Date: Mon, 23 Apr 2007 04:42:45 +0200 From: Ingo Molnar <mingo@...e.hu> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: 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>, Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>, Arjan van de Ven <arjan@...radead.org>, Peter Williams <pwil3058@...pond.net.au>, Thomas Gleixner <tglx@...utronix.de>, caglar@...dus.org.tr, Gene Heskett <gene.heskett@...il.com> Subject: [report] renicing X, cfs-v5 vs sd-0.46 * Linus Torvalds <torvalds@...ux-foundation.org> wrote: > The X server should not be re-niced. It was done in the past, and it > was wrogn then (and caused problems - we had to tell people to undo > it, because some distros had started doing it by default). > > If you have a single client, the X server is *not* more important than > the client, and indeed, renicing the X server causes bad patterns: > just because the client sends a request does not mean that the X > server should immediately be given the CPU as being "more important". You are completely right in the case of traditional schedulers. Note that this is not the case for CFS though. CFS has natural, built-in buffering against high-rate preemptions from lower nice-level SCHED_OTHER tasks. So while X will indeed get more CPU time (and that i think is fully justified), it wont get nearly as high of a context-switch rate as under priority/runqueue-based schedulers. To demonstrate this i have done the following simple experiment: i started 4 xterms on a single-CPU box, then i started the 'yes' utility in each xterm and resized all of the xterms to just 2 lines vertical. This generates a _lot_ of screen refresh events. Naturally, such a workload utilizes the whole CPU. Using CFS-v5, with Xorg at nice 0, the context-switch rate is low: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 472132 13712 178604 0 0 0 32 113 170 83 17 0 0 0 2 0 0 472172 13712 178604 0 0 0 0 112 184 85 15 0 0 0 2 0 0 472196 13712 178604 0 0 0 0 108 162 83 17 0 0 0 1 0 0 472076 13712 178604 0 0 0 0 115 189 86 14 0 0 0 X's CPU utilization is 49%, xterm's go to 12% each. Userspace utilization is 85%, system utilization is 15%. Renicing X to -10 increases context-switching, but not dramatically so, because it is throttled by CFS: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 475752 13492 176320 0 0 0 64 116 1498 85 15 0 0 0 4 0 0 475752 13492 176320 0 0 0 0 107 1488 84 16 0 0 0 4 0 0 475752 13492 176320 0 0 0 0 140 1514 86 14 0 0 0 4 0 0 475752 13492 176320 0 0 0 0 107 1477 85 15 0 0 0 4 0 0 475752 13492 176320 0 0 0 0 122 1498 84 16 0 0 0 The system is still usable, Xorg is 44% busy, each xterm is 14% busy. User utilization 85%, system utilization is 15% - just like in the first case. "Performance of scrolling" is exactly the same in both cases (i have tested this by inserting periodic beeps after every 10,000 lines of text scrolled) - but the screen refresh rate is alot more eye-pleasing in the nice -10 case. (screen refresh it happens at ~500 Hz, while in the nice 0 case it happens at ~40 Hz and visibly flickers. This is especially noticeable if the xterms have full size.) I have tested the same workload on vanilla v2.6.21-rc7 and on SD-0.46 too, and they give roughly the same xterm scheduling behavior when Xorg is at nice 0: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 450564 14844 194976 0 0 0 0 287 594 58 10 32 0 0 4 0 0 450704 14844 194976 0 0 0 0 108 370 89 11 0 0 0 0 0 0 449588 14844 194976 0 0 0 0 175 434 85 13 2 0 0 3 0 0 450688 14852 194976 0 0 0 32 242 315 62 9 29 0 0 but when Xorg is reniced to -10 on the vanilla or SD schedulers, it indeed gives the markedly higher context-switching behavior you predicted: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 452272 13936 194896 0 0 0 0 126 14147 78 22 0 0 0 4 0 0 452252 13944 194896 0 0 0 64 155 14143 80 20 0 0 0 5 0 0 452612 13944 194896 0 0 0 0 187 14031 79 21 0 0 0 4 0 0 452624 13944 194896 0 0 0 0 121 14300 82 18 0 0 0 User time drops to 78%, system time increases to 22%. "Scrolling performance" clearly decreases. so i agree that renicing X can be a very bad idea, but it very much depends on the scheduler implementation too. 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/
Powered by blists - more mailing lists