linux-kernel - Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)

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:	Fri, 27 Apr 2007 22:06:44 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Mike Galbraith <efault@....de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS
 is under heavy write load (massive starvation)


On Apr 27 2007 08:18, Linus Torvalds wrote:
>
>Actually, you don't need to apply the patch - just do
>
>	echo 5 > /proc/sys/vm/dirty_background_ratio
>	echo 10 > /proc/sys/vm/dirty_ratio
>
>and say if it seems to improve things. I think those are much saner 
>defaults especially for a desktop system (and probably for most servers 
>too, for that matter).

Interesting. For my laptop, I have configured like 90 for
dirty_background_ratio and 95 for dirty_ratio. Makes for a nice
delayed write, but I do not do workloads bigger than extracing kernel
tarballs (~250 MB) and coding away on that machine (488 MB RAM) anyway.
Setting it to something like 95, I could probably rm -Rf the kernel
tree again and the disk never gets active because it is all cached.
But if dirty_ratio is lowered, the disk will get active soon.

>Historical note: allowing about half of memory to contain dirty pages made 
>more sense back in the days when people had 16-64MB of memory, and a 
>single untar of even fairly small projects would otherwise hit the disk. 
>But memory sizes have grown *much* more quickly than disk speeds (and 
>latency requirements have gone down, not up), so a default that may 
>actually have been perfectly fine at some point seems crazy these days..



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