Re: [PATCH v2 -mm 1/3] mm: reclaim at order 0 when compaction isenabled

[Rik van Riel]

On 01/25/2012 11:07 AM, Mel Gorman wrote:
> On Wed, Jan 25, 2012 at 10:27:28AM -0500, Rik van Riel wrote:

> > Maybe this is the place to check (in balanced_pgdat) ?
> >
> >                  /*
> >                   * We do this so kswapd doesn't build up large
> > priorities for
> >                   * example when it is freeing in parallel with
> > allocators. It
> >                   * matches the direct reclaim path behaviour in
> > terms of impact
> >                   * on zone->*_priority.
> >                   */
> >                  if (sc.nr_reclaimed>= SWAP_CLUSTER_MAX)
> >                          break;
>
> It would be a good place all right. Preferably it would tie into
> compaction_ready() to decide whether to continue reclaiming or not.

Good point. We can just track compaction_ready for all
of the zones and bail out if at least one of the zones
is ready for compaction (somehow taking the classzone
index into account?).

Or maybe simply keep reclaiming order 0 pages until all
the memory zones in the pgdat are ready for compaction?

> > > > @@ -2922,8 +2939,6 @@ out:
> > > >
> > > >   			/* If balanced, clear the congested flag */
> > > >   			zone_clear_flag(zone, ZONE_CONGESTED);
> > > > -			if (i<= *classzone_idx)
> > > > -				balanced += zone->present_pages;
> > > >   		}
> > >
> > > Why is this being deleted? It is still used by pgdat_balanced().
> >
> > This is outside of the big while loop and is not used again
> > in the function.
>
> How about here?
>
>                 if (all_zones_ok || (order&&  pgdat_balanced(pgdat, balanced, *classzone_idx)))
>                          break;          /* kswapd: all done */
>
> Either way, it looks like something that should be in its own patch.

That code is above the lines that I removed.

The only way to get back there is to jump up to
loop_again, from where we will get to the main loop,
where balanced is zeroed out.

If you want I will split this out into its own patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/