From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <clameter@sgi.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 17/20] non-reclaimable mlocked pages
Date: Fri, 21 Dec 2007 12:13:43 -0500 [thread overview]
Message-ID: <1198257223.5273.9.camel@localhost> (raw)
In-Reply-To: <20071220103332.11c4bbd2@bree.surriel.com>
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@sgi.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-12-21 17:13 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 21:15 [patch 00/20] VM pageout scalability improvements Rik van Riel
2007-12-18 21:15 ` [patch 01/20] convert anon_vma list lock a read/write lock Rik van Riel
2007-12-20 7:07 ` Christoph Lameter
2007-12-18 21:15 ` [patch 02/20] make the inode i_mmap_lock a reader/writer lock Rik van Riel
2007-12-19 0:48 ` Nick Piggin
2007-12-19 4:09 ` KOSAKI Motohiro
2007-12-19 15:52 ` Lee Schermerhorn
2007-12-19 16:31 ` Rik van Riel
2007-12-19 16:53 ` Lee Schermerhorn
2007-12-19 19:28 ` Peter Zijlstra
2007-12-19 23:40 ` Nick Piggin
2007-12-20 7:04 ` Christoph Lameter
2007-12-20 7:59 ` Nick Piggin
2008-01-02 23:35 ` Mike Travis
2008-01-03 6:07 ` Nick Piggin
2008-01-03 8:55 ` Ingo Molnar
2008-01-07 9:01 ` Nick Piggin
2007-12-18 21:15 ` [patch 03/20] move isolate_lru_page() to vmscan.c Rik van Riel
2007-12-20 7:08 ` Christoph Lameter
2007-12-18 21:15 ` [patch 04/20] free swap space on swap-in/activation Rik van Riel
2007-12-18 21:15 ` [patch 05/20] define page_file_cache() function Rik van Riel
2007-12-18 21:15 ` [patch 06/20] debugging checks for page_file_cache() Rik van Riel
2007-12-18 21:15 ` [patch 07/20] Use an indexed array for LRU variables Rik van Riel
2007-12-18 21:15 ` [patch 08/20] split LRU lists into anon & file sets Rik van Riel
2007-12-18 21:15 ` [patch 09/20] split anon & file LRUs for memcontrol code Rik van Riel
2007-12-18 21:15 ` [patch 10/20] SEQ replacement for anonymous pages Rik van Riel
2007-12-19 5:17 ` KOSAKI Motohiro
2007-12-19 13:40 ` Rik van Riel
2007-12-20 2:04 ` KOSAKI Motohiro
2007-12-18 21:15 ` [patch 11/20] add newly swapped in pages to the inactive list Rik van Riel
2007-12-18 21:15 ` [patch 12/20] No Reclaim LRU Infrastructure Rik van Riel
2007-12-18 21:15 ` [patch 13/20] Non-reclaimable page statistics Rik van Riel
2007-12-18 21:15 ` [patch 14/20] Scan noreclaim list for reclaimable pages Rik van Riel
2007-12-18 21:15 ` [patch 15/20] ramfs pages are non-reclaimable Rik van Riel
2007-12-18 21:15 ` [patch 16/20] SHM_LOCKED pages are nonreclaimable Rik van Riel
2007-12-18 21:15 ` [patch 17/20] non-reclaimable mlocked pages Rik van Riel
2007-12-19 0:56 ` Nick Piggin
2007-12-19 13:45 ` Rik van Riel
2007-12-19 14:24 ` Peter Zijlstra
2007-12-19 14:53 ` Rik van Riel
2007-12-19 16:08 ` Lee Schermerhorn
2007-12-19 16:04 ` Lee Schermerhorn
2007-12-20 20:56 ` Rik van Riel
2007-12-21 10:52 ` Nick Piggin
2007-12-21 14:17 ` Rik van Riel
2007-12-23 12:22 ` Nick Piggin
2007-12-24 1:00 ` Rik van Riel
2007-12-19 23:34 ` Nick Piggin
2007-12-20 7:19 ` Christoph Lameter
2007-12-20 15:33 ` Rik van Riel
2007-12-21 17:13 ` Lee Schermerhorn [this message]
2007-12-18 21:15 ` [patch 18/20] mlock vma pages under mmap_sem held for read Rik van Riel
2007-12-18 21:15 ` [patch 19/20] handle mlocked pages during map/unmap and truncate Rik van Riel
2007-12-18 21:15 ` [patch 20/20] account mlocked pages Rik van Riel
2007-12-22 20:27 ` [patch 00/20] VM pageout scalability improvements Balbir Singh
2007-12-23 0:21 ` Rik van Riel
2007-12-23 22:59 ` Balbir Singh
2007-12-24 1:11 ` Rik van Riel
2007-12-28 3:20 ` Matt Mackall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1198257223.5273.9.camel@localhost \
--to=lee.schermerhorn@hp.com \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).