Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable

Lee Schermerhorn
2008-06-11T15:29:10Z

On Tue, 2008-06-10 at 19:48 -0400, Rik van Riel wrote:
> 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

In vmscan, true. try_to_unmap() will catch it too. By then, we'll have
let the page ride through the active list to the inactive list and won't
catch it until shrink_page_list(). But, this only happens once per page
and then it's hidden on the nor^H^H^Hunevictable list.

We might want to kill the "cull in fault path" patch, tho'.

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

Not sure. The most recent patches that I posted do not use the pagevec
for the noreclaim/unevictable list. They put nonreclaimable/unevictable
pages directly onto the noreclaim/unevictable list to avoid race
conditions that could strand a page. Kosaki-san and I spent a lot of
time analyzing and testing the current code for potential page leaks
onto the noreclaim/unevictable list. It currently depends on the atomic
TestSet/TestClear of the PG_mlocked bit, along with page lock and lru
isolation/putback to resolve all of the potential races. I attempted to
describe this aspect in the doc. Have to rethink all of that.