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: <Pine.LNX.4.64.0708141233370.30435@schroedinger.engr.sgi.com>
Date:	Tue, 14 Aug 2007 12:41:10 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	linux-mm@...ck.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

On Tue, 14 Aug 2007, Peter Zijlstra wrote:

> > Ok but that could be addressed by making sure that a certain portion of 
> > memory is reserved for clean file backed pages.
> 
> Which gets us back to the initial problem of sizing this portion and
> ensuring it is big enough to service the need.

Clean file backed pages dominate memory on most boxes. They can be 
calculated by NR_FILE_PAGES - NR_FILE_DIRTY

On my 2G system that is 

Cached:        1731480 kB
Dirty:             424 kB

So for most load the patch as is will fix your issues. The problem arises 
if you have extreme loads that are making the majority of pages anonymous.

We could change min_free_kbytes to specify the number of free + clean 
pages required (if we can do atomic reclaim then we do not need it 
anymore). Then we can specify a large portion of memory for 
min_free_kbytes. 20%? That would give you 400M on my box which would 
certainly suffice.

If the amount of clean file backed pages falls below that limit then do 
the usual reclaim. If we write anonymous pages out to swap then they 
can also become clean and reclaimable.


-
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