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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux