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]

Message-ID: <Pine.LNX.4.64.0702030946330.5388@schroedinger.engr.sgi.com>
Date:	Sat, 3 Feb 2007 09:56:33 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	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, Andrew Morton wrote:

> I wonder if it can be simpler.  Make two changes:

Would be great if this could get simpler.

> a) If the scanner encounters an mlocked page on the LRU, take it off.

The current patch takes them off when mlock is set (which may not work 
since the page may be off the LRU) and then has the scanner taking them 
off. We could just remove the early one but what would this bring us?

> b) munlock() adds all affected pages to the LRU.

Hmmm... You mean without checking all the vmas of a page for VM_LOCKED? So they 
are going to be removed again on the next pass? Ok. I see that makes it 
simpler but it requires another reclaim scan.

> doesn't consume a page flag.  Optional (and arguable) extension: scan the
> vmas during munmap, don't add page to LRU if it's still mlocked.
> 
> Why _does_ your patch add a new page flag?  That info is available via a
> vma scan.

The page flag allows a clean state transition of a page and accurate 
keeping of statistics for MLOCKed pages. There were objections against the 
fuzzy counting in the earlier incarnation and it was proposed that a page 
flag be introduced. Without the flag we cannot know that the page is 
already mapped by a VM_LOCKED vma without scanning over all vmas 
referencing the page.

> > 1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
> 
> Ow.  How were you thinking of fixing that?

I thought someone else could come up with something. Maybe the one that 
told me to use another page flag?

> > 2. Since mlocked pages are now off the LRU page migration will no longer
> >    move them.
> 
> Ow.  That could be a right pain when we get around to using migration for
> memory-unplug?

We need to expand page migration anyways to allow the gerneral migration 
of non-LRU pages.
-
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/