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] [day] [month] [year] [list]

Message-ID: <20090114032932.GC17395@wotan.suse.de>
Date:	Wed, 14 Jan 2009 04:29:32 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Chris Mason <chris.mason@...cle.com>,
	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	peterz@...radead.org, jack@...e.cz, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: Increase dirty_ratio and dirty_background_ratio?

On Thu, Jan 08, 2009 at 09:05:01AM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 8 Jan 2009, Chris Mason wrote:
> > 
> > Does it make sense to hook into kupdate?  If kupdate finds it can't meet
> > the no-data-older-than 30 seconds target, it lowers the sync/async combo
> > down to some reasonable bottom.  
> > 
> > If it finds it is going to sleep without missing the target, raise the
> > combo up to some reasonable top.
> 
> I like autotuning, so that sounds like an intriguing approach. It's worked 
> for us before (ie VM).
> 
> That said, 30 seconds sounds like a _loong_ time for something like this. 
> I'd use the normal 5-second dirty_writeback_interval for this: if we can't 
> clean the whole queue in that normal background writeback interval, then 
> we try to lower the tagets. We already have that "congestion_wait()" thing 
> there, that would be a logical place, methinks.
> 
> I'm not sure how to raise them, though. We don't want to raise any limits 
> just because the user suddenly went idle. I think the raising should 
> happen if we hit the sync/async ratio, and we haven't lowered in the last 
> 30 seconds or something like that.

The other problem is that the pagecache is quite far removed from the
block device. Writeback can go to different devices, and those devices
might have different speeds at different times or different patterns.

We might autosize our dirty data to 500MB when doing linear writes because
our block device is happily cleaning them at 100MB/s and latency is
great. But then if some process inserts even 20MB worth of very seeky dirty
pages, the time to flush can go up by an order of magnitude. Let alone
500MB.

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