linux-kernel - Re: [RFC] Tracking mlocked pages and moving them off the LRU

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:	Sat, 3 Feb 2007 17:22:42 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU

On Sat, 3 Feb 2007 11:03:59 -0800 (PST) Christoph Lameter <clameter@....com> wrote:

> Here is the second piece removing mlock pages off the LRU during scanning. 
> I tried moving them to a separate list but then we run into issues with
> locking. We do not need ithe list though since we will encounter the
> page again anyways during zap_pte_range.
> 
> However, in zap_pte_range we then run into another problem. Multiple 
> zap_pte_ranges may handle the same page and without a page flag and 
> scanning all the vmas we cannot determine if the page should or should not 
> be moved back to the LRU. As a result this patch may decrement NR_MLOCK 
> too much so that is goes below zero. Any ideas on how to fix this without 
> a page flag and a scan over vmas?
> 
> Plus there is the issue of NR_MLOCK only being updated when we are 
> reclaiming and when we may already be in trouble. An app may mlock huge 
> amounts of memory and NR_MLOCK will stay low. If memory gets too low then
> NR_MLOCKED is suddenly become accurate and the VM is likely undergoing a 
> shock from that discovery (should we actually use NR_MLOCK elsewhere to 
> determine memory management behavior). Hopefully we will not fall over 
> then.

Do we actually need NR_MLOCK?  Page reclaim tends to care more about the
size of the LRUs and doesn't have much dependency on ->present_pages,
iirc.

I guess we could use NR_MLOCK for writeback threshold calculations, to
force writeback earlier if there's a lot of mlocked memory in the affected
zones.  But that code isn't zone-aware anyway, and we don't know how to make
it zone aware in any sane fashion and making it cpuset-aware isn't very
interesting or useful..

So..  Why do we want NR_MLOCK?
-
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/