lkml.org 
[lkml]   [2008]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable
On Tue, 10 Jun 2008 17:43:17 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> On Tue, 2008-06-10 at 17:14 -0400, Rik van Riel wrote:
> > On Tue, 10 Jun 2008 05:31:30 +0200
> > Nick Piggin <npiggin@suse.de> wrote:
> >
> > > If we eventually run out of page flags on 32 bit, then sure this might be
> > > one we could look at geting rid of. Once the code has proven itself.
> >
> > Yes, after the code has proven stable, we can probably get
> > rid of the PG_mlocked bit and use only PG_unevictable to mark
> > these pages.
> >
> > Lee, Kosaki-san, do you see any problem with that approach?
> > Is the PG_mlocked bit really necessary for non-debugging
> > purposes?
>
> Well, it does speed up the check for mlocked pages in page_reclaimable()
> [now page_evictable()?] as we don't have to walk the reverse map to
> determine that a page is mlocked. In many places where we currently
> test page_reclaimable(), we really don't want to and maybe can't walk
> the reverse map.

There are a few places:
1) the pageout code, which calls page_referenced() anyway; we can
change page_referenced() to return PAGE_MLOCKED and do the right
thing from there
2) when the page is moved from a per-cpu pagevec onto an LRU list,
we may be able to simply skip the check there on the theory that
the pagevecs are small and the pageout code will eventually catch
these (few?) pages - actually, setting PG_noreclaim on a page
that is in a pagevec but not on an LRU list might catch that

Does that seem reasonable/possible?

--
All rights reversed.


\
 
 \ /
  Last update: 2008-06-11 01:53    [W:0.173 / U:1.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site