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: <20070618164711.9de1c38e.akpm@linux-foundation.org>
Date:	Mon, 18 Jun 2007 16:47:11 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	tim.c.chen@...ux.intel.com
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Change in default vm_dirty_ratio

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

> Andrew,
> 
> The default vm_dirty_ratio changed from 40 to 10
> for the 2.6.22-rc kernels in this patch:
>  
> http://git.kernel.org/?
> p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=07db59bd6b0f279c31044cba6787344f63be87ea;hp=de46c33745f5e2ad594c72f2cf5f490861b16ce1
> 
> IOZone write drops by about 60% when test file size is 50 percent of
> memory.  Rand-write drops by 90%. 

heh.

(Or is that an inappropriate reaction?)

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

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

> How will it help for most cases?  Intuitively, it seems like 
> a less aggressive writeback will have better performance.

I assume that iozone is either doing a lot of file overwrites or is
unlinking/truncating files shortly after having written them.

And some benchmarks are silly.  You have just demonstrated that IOZone
should have been called RAMZone....

Some workloads will work more nicely with this change and others will be
hurt.  Where does the optimum lie?  Don't know.  Nowhere, really.

Frankly, I find it very depressing that the kernel defaults matter.  These
things are trivially tunable and you'd think that after all these years,
distro initscripts would be establishing the settings, based upon expected
workload, amount of memory, number and bandwidth of attached devices, etc.

Heck, there should even be userspace daemons which observe ongoing system
behaviour and which adaptively tune these things to the most appropriate
level.

But nope, nothing.

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