linux-kernel - Re: [patch 17/20] non-reclaimable mlocked pages

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: <1198257223.5273.9.camel@localhost>
Date:	Fri, 21 Dec 2007 12:13:43 -0500
From:	Lee Schermerhorn <Lee.Schermerhorn@...com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Christoph Lameter <clameter@....com>,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 17/20] non-reclaimable mlocked pages

On Thu, 2007-12-20 at 10:33 -0500, Rik van Riel wrote:
> On Wed, 19 Dec 2007 23:19:00 -0800 (PST)
> Christoph Lameter <clameter@....com> wrote:
> 
> > On Wed, 19 Dec 2007, Nick Piggin wrote:
> > 
> > > These mlocked pages don't need to be on a non-reclaimable list,
> > > because we can find them again via the ptes when they become
> > > unlocked, and there is no point background scanning them, because
> > > they're always going to be locked while they're mlocked.
> > 
> > But there is something to be said for having a consistent scheme. 
> 
> The code as called from .c files should indeed be consistent.
> 
> However, since we never need to scan the non-reclaimable list,
> we could use the inline functions in the .h files to have an
> mlock count instead of a .lru list head in the non-reclaimable
> pages.
> 
> At least, I think so.  I'm going to have to think about the
> details a lot more.  I have no idea yet if there will be any
> impact from batching the pages on pagevecs, vs. an atomic
> mlock count...

Just remember that page migration can migrate mlocked pages today, and
we'll want to continue to support this.  Migration uses the lru locks to
manage the pages selected for migration and uses isolation from lru list
under zone lru_lock to arbitrate any racing migrations.  Unless mlocked
pages are kept on an lru-like list, we'll need to put them back during
migration--possibly losing the mlock count or needing to save it
somewhere over [possibly lazy] migration.  

Note that having mlocked pages on the noreclaim lru list doesn't mean we
have to scan them to reclaim them.  It does however mean that we'd have
to skip over them to scan other types of non-reclaimable pages.  What
other types?  In my current implementation, SHM_LOCKed pages and
ramdisk/fs pages aren't mlocked.  Rather, they are culled to the
noreclaim list in vmscan when we detect a page on the [in]active list
that is in a nonreclaimable mapping.  This required minimal changes to
recognize and cull these nonreclaimable pages.  Currently PG_mlocked is
used only for pages mapped into a VM_LOCKED vma.  Since the noreclaim
list exists for the other types [and there could be more], it's little
additional work to keep mlocked pages there as well.  This makes them
play nice with migration.

Lee

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