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: <4918AFA1.4000102@gmail.com>
Date:	Mon, 10 Nov 2008 23:03:13 +0100
From:	Andrea Righi <righi.andrea@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	kamezawa.hiroyu@...fujitsu.com, rientjes@...gle.com,
	balbir@...ux.vnet.ibm.com, mrubin@...gle.com, menage@...gle.com,
	dave@...ux.vnet.ibm.com, chlunde@...g.uio.no, dpshah@...gle.com,
	eric.rannaud@...il.com, fernando@....ntt.co.jp, agk@...rceware.org,
	m.innocenti@...eca.it, s-uchida@...jp.nec.com, ryov@...inux.co.jp,
	matt@...ehost.com, dradford@...ehost.com,
	kosaki.motohiro@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, containers@...ts.osdl.org
Subject: Re: [PATCH -mm] mm: fine-grained dirty_ratio_pcm and dirty_background_ratio_pcm
 (v2)

On 2008-11-10 22:12, Andrew Morton wrote:
> On Mon, 10 Nov 2008 21:58:28 +0100
> Andrea Righi <righi.andrea@...il.com> wrote:
> 
>> The current granularity of 5% of dirtyable memory for dirty pages writeback is
>> too coarse for large memory machines and this will get worse as
>> memory-size/disk-speed ratio continues to increase.
>>
>> These large writebacks can be unpleasant for desktop or latency-sensitive
>> environments, where the time to complete each writeback can be perceived as a
>> lack of responsiveness by the whole system.
>>
>> Following there's a similar solution as discussed in [1], but a little
>> bit simplified in order to provide the same functionality (in particular
>> to avoid backward compatibility problems) and reduce the amount of code
>> needed to implement an in-kernel parser to handle percentages with
>> decimals digits.
>>
>> The kernel provides the following parameters:
>>  - dirty_ratio, dirty_background_ratio in percentage (1 ... 100)
>>  - dirty_ratio_pcm, dirty_background_ratio_pcm in units of percent mille (1 ... 100,000)
> 
> hm, so how long until dirty_ratio_pcm becomes too coarse...
> 
> What happened to the idea of specifying these in units of kilobytes?

The conclusion was that with units in KB requires much more complexity
to keep in sync the old dirty_ratio (and dirty_background_ratio)
interface with the new one.

The KB limit is a static value, the other depends on the dirtyable
memory. If we want to preserve the same behaviour we should do the
following:

- when dirty_ratio changes to x:
  dirty_amount_in_bytes = x * dirtyable_memory / 100.

- when dirty_amount_in_bytes changes to x:
  dirty_ratio = x / dirtyable_memory * 100

But anytime the dirtyable memory changes (as well as the total memory in
the system) we should update both values accordingly to preserve the
coherency between them.

I wonder if setting also PERCENT_PCM (that is 1% expressed in
fine-grained units) as a parameter could be a better long-term solution.
And also use another name for it, because in this case this would be not
a milli-percent value anymore.

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