linux-kernel - Re: [RFC] [PATCH -mm 0/2] memcg: per cgroup 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: <532480950809231321g7be0dd09pe6a32426b361e676@mail.gmail.com>
Date:	Tue, 23 Sep 2008 13:21:18 -0700
From:	"Michael Rubin" <mrubin@...gle.com>
To:	"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>, dradford@...ehost.com,
	m.innocenti@...eca.it, fernando@....ntt.co.jp,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, chlunde@...g.uio.no,
	dave@...ux.vnet.ibm.com, dpshah@...gle.com, agk@...rceware.org,
	matt@...ehost.com, menage@...gle.com,
	"Andrea Righi" <righi.andrea@...il.com>, eric.rannaud@...il.com,
	balbir@...ux.vnet.ibm.com
Subject: Re: [RFC] [PATCH -mm 0/2] memcg: per cgroup dirty_ratio

On Tue, Sep 23, 2008 at 10:48 AM, KOSAKI Motohiro
<kosaki.motohiro@...fujitsu.com> wrote:
> Why vm_dirty_ratio = 0.125 is wrong?
> it is hardly for parser maker, but it have nicer user experience.

Here's an idea to build off Kosaki's suggestion and incorporate other
previous suggestions.

What if we have two knobs for every ratio. So we could have
vm_dirty_ratio and also vm_dirty_KB

vm_dirty_KB allows the user to set the number of KB desired and also
read the amount of KB that has been set.

Writing to vm_dirty_ratio works just as before and only allows whole
percentages.
Reading from vm_dirty_ratio will return a reply as before except if KB
has been set it can return a number in percentages (rounded off to
thousandths).

This way we allow new functionality and preserve old functionality
while not surprising the user.
Maybe we should deprecate the vm_dirty_ratio interface also and point
folks to the vm_dirty_KB.

> We don't have any motivation of its interface change.

We are seeing problems where we are generating a lot of dirty memory
from asynchronous background writes while more important traffic is
operating with DIRECT_IO. The DIRECT_IO traffic will incur high
latency spikes as the pdflush hits the background threshold and tries
to write a lot of dirty buffers at once.

What we want to do is lower the background threshold low enough so
that we don't end up writing a lot of data at one time. As systems get
more and more memory this is and will become difficult. 1% of system
RAM could tie up a disk.

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