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:	Wed, 19 Dec 2007 08:40:58 -0500
From:	Rik van Riel <riel@...hat.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	kosaki.motohiro@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, lee.shermerhorn@...com
Subject: Re: [patch 10/20] SEQ replacement for anonymous pages

On Wed, 19 Dec 2007 14:17:53 +0900
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> wrote:

> Hi Rik-san,
> 
> > To keep the maximum amount of necessary work reasonable, we scale the
> > active to inactive ratio with the size of memory, using the formula
> > active:inactive ratio = sqrt(memory in GB * 10).

> why do you think best formula is sqrt(GB*10)?
> please tell me if you don't mind.

On a 1GB system, this leads to a ratio of 3 active anon
pages to 1 inactive anon page, and a maximum inactive
anon list size of 250MB.
 
On a 1TB system, this leads to a ratio of 100 active anon
pages to 1 inactive anon page, and a maximum inactive
anon list size of 10GB.

The numbers in-between looked reasonable :)

Basically the requirement is that the inactive anon list 
is large enough that pages get a chance to be referenced
again, but small enough that the maximum amount of work
the VM needs to do is bounded to something reasonable.

> and i have a bit worry to it works well or not on small systems.
> because it is indicate 1:1 ratio on less than 100MB memory system.
> Do you think this viewpoint?

A 1:1 ratio simply means that the inactive anon list is
the same size as the active anon list. Page replacement
should still work fine that way.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
--
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