linux-kernel - Re: Increase dirty_ratio and dirty_background

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:	Thu, 08 Jan 2009 12:01:01 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	jack@...e.cz
Cc:	torvalds@...ux-foundation.org, chris.mason@...cle.com,
	akpm@...ux-foundation.org, peterz@...radead.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, npiggin@...e.de
Subject: Re: Increase dirty_ratio and dirty_background_ratio?

From: Jan Kara <jack@...e.cz>
Date: Thu, 8 Jan 2009 20:57:28 +0100

>   But I think there are workloads for which this is suboptimal to say the
> least. Imagine you do some crazy LDAP database crunching or other similar load
> which randomly writes to a big file (big means it's size is rougly
> comparable to your available memory). Kernel finds pdflush isn't able to
> flush the data fast enough so we decrease dirty limits. This results in
> even more agressive flushing but that makes things even worse (in a sence
> that your application runs slower and the disk is busy all the time anyway).
> This is the kind of load where we observe problems currently.

I'm pretty sure this is what I see as well.

If you just barely fit your working GIT state into memory, and you are
not using "noatime" on that partition, doing a bunch of git operations
is just going to trigger all of this forced and blocking writeback on
the atime dirtying of the inodes, and this will subsequently grind
your machine to a halt if your disk is slow.
--
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/