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: <45E77D41.1080408@hitachi.com>
Date:	Fri, 02 Mar 2007 10:26:25 +0900
From:	Tomoki Sekiyama <tomoki.sekiyama.qu@...achi.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	miklos@...redi.hu, yumiko.sugita.yf@...achi.com,
	masami.hiramatsu.pt@...achi.com, hidehiro.kawai.ez@...achi.com,
	yuji.kakutani.uw@...achi.com, soshima@...hat.com, haoki@...hat.com,
	nikita@...sterfs.com
Subject: Re: [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers

Hi Kamezawa-san,

KAMEZAWA Hiroyuki wrote:
>>> >>> Interesting, but how about adjust this parameter like below instead of
>>> >>> adding new control knob ?(this kind of knob is not easy to use.)
<snip>
>>> >>> count_dirty_pages_on_device_limited(bdi, writechunk) above returns
>>> >>> dirty pages on bdi. if # of dirty_pages on bdi is larger than writechunk,
>>> >>> just returns writechunk.
>> >>
>> >> I think that way is not enough to control the total amount of
>> >> Dirty+Writeback.
>> >>
>> >> In that way, while writeback_inodes() scans for dirty pages and writes
>> >> them back, the caller will be blocked only if the length of the write-
>> >> requests queue is longer than nr_requests.

> > What nr_request means ?

nr_requests is a parameter that means upper limit of the length of I/O
(read- and write-)requests queue of the device, which is configurable
from /sys/block/<device>/queue/nr_requests. A process, which perform I/O
when there are more than nr_requests requests in the queue, will be blocked.

> > But Ok, maybe I'm not understanding. What I want to ask you is do
> > per-device-write-throttling rather than adding a new parameter.

In the patchset, per-device-write-throttling is done by the behavior
of the write-requests queue described above.

When the queue of the disk becomes full while writeback of Dirty in
writeback_inodes(), heavy writes to the disk will be blocked.
In contrast, if it's so occasional that the queue doesn't become full,
writes will not be blocked.


Regards
--
Tomoki Sekiyama
Hitachi, Ltd., Systems Development Laboratory
-
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