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

[Andrew Morton <akpm@linux-foundation.org>]

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.


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