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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ