linux-kernel - Re: Change in default vm_dirty

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]

Message-ID: <18040.9056.755569.67029@stoffel.org>
Date:	Tue, 19 Jun 2007 14:41:36 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	tim.c.chen@...ux.intel.com, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Change in default vm_dirty_ratio

>>>>> "Andrew" == Andrew Morton <akpm@...ux-foundation.org> writes:

Andrew> On Mon, 18 Jun 2007 14:14:30 -0700
Andrew> Tim Chen <tim.c.chen@...ux.intel.com> wrote:

>> IOZone write drops by about 60% when test file size is 50 percent of
>> memory.  Rand-write drops by 90%. 

Andrew> heh.

Andrew> (Or is that an inappropriate reaction?)

>> Is there a good reason for turning down the default dirty ratio?

Andrew> It seems too large.  Memory sizes are going up faster than
Andrew> disk throughput and it seems wrong to keep vast amounts of
Andrew> dirty data floating about in memory like this.  It can cause
Andrew> long stalls while the system writes back huge amounts of data
Andrew> and is generally ill-behaved.

Shouldn't the vm_dirty_ratio be based on the speed of the device, and
not the size of memory?  So slower devices can't keep as much in
memory as fast devices?  That would seem to be a better metric.  And
of course those with hundreds of disks will then complain we're taking
too much memory as well, even though they can handle it.  

So per-device vm_dirty_ratio, capped with a vm_dirty_total_ratio seems
to be what we want, right?

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