Re: [rfc] [patch] mm: zone_reclaim fix for pseudo file systems

Andrew Morton
2007-07-31T02:27:21Z

On Mon, 30 Jul 2007 19:01:07 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Mon, 30 Jul 2007, Ravikiran G Thirumalai wrote:
>
> > On Mon, Jul 30, 2007 at 05:27:41PM -0700, Christoph Lameter wrote:
> > >On Mon, 30 Jul 2007, Andrew Morton wrote:
> > >
> > >> The problem is that __zone_reclaim() doesn't use all_unreclaimable at all.
> > >> You'll note that all the other callers of shrink_zone() do take avoiding
> > >> action if the zone is in all_unreclaimable state, but __zone_reclaim() forgot
> > >> to.
> > >
> > >zone reclaim only runs if there are unmapped file backed pages that can be
> > >reclaimed.
> >
> > Yes, and in this case, without the patch, VM considers RAMFS pages to be
> > file backed, thus being fooled into entering reclaim. The process entering
> > into reclaim in our tests gets in through zone_reclaim.

Oh.. So this:

/*
* Zone reclaim reclaims unmapped file backed pages and
* slab pages if we are over the defined limits.
*
* A small portion of unmapped file backed pages is needed for
* file I/O otherwise pages read by file I/O will be immediately
* thrown out if the zone is overallocated. So we do not reclaim
* if less than a specified percentage of the zone is used by
* unmapped file backed pages.
*/
if (zone_page_state(zone, NR_FILE_PAGES) -
zone_page_state(zone, NR_FILE_MAPPED) <= zone->min_unmapped_pages
&& zone_page_state(zone, NR_SLAB_RECLAIMABLE)
<= zone->min_slab_pages)
return 0;

is being fooled.

That makes sense, but any fix we do here won't fix things for regular
reclaim.

Sigh, I should have spotted that bug on day one - it's pretty gross. Too
many patches, too little akpm.

> That means RAMFS pages are accounted as NR_FILE_PAGES but not as
> NR_FILE_MAPPED..... So we have unmapped pages that are not reclaimable.
>
> But they are not really file backed pages. They are backed by memory. Can
> we just not increment NR_FILE_MAPPED? Should they not be accounted for an
> NR_ANON_PAGES or so?

Or we change NR_FILE_MAPPED accounting so that it doesn't account
BDI_CAP_foo pages, where foo is, I guess, NO_WRITEBACK.

We're going to create a mess here, I can feel it. Please, ignore "what works".
What is _right_ here? What is our design? Our guiding principle? Because we
already have a mess.

Straw man proposal:

- account file-backed pages, BDI_CAP_NO_ACCT_DIRTY pages and
BDI_CAP_NO_WRITEBACK separately. ie: zone accounting pretty
much follows the BDI_CAP_ selectors.

- work out, then document what those BDI_CAP_* things actually _mean_. ie:
which sorts of callers should set them, and why.

- do the appropriate arith at reclaim-time.