Re: [patch 2/8] mm: memcg-aware global reclaim

[Johannes Weiner]

On Mon, Aug 29, 2011 at 12:15:57AM -0700, Ying Han wrote:
> On Thu, Aug 11, 2011 at 2:09 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> >
> > On Thu, Aug 11, 2011 at 01:39:45PM -0700, Ying Han wrote:
> > > Please consider including the following patch for the next post. It causes
> > > crash on some of the tests where sc->mem_cgroup is NULL (global kswapd).
> > >
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index b72a844..12ab25d 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -2768,7 +2768,8 @@ loop_again:
> > >                          * Do some background aging of the anon list, to
> > > give
> > >                          * pages a chance to be referenced before
> > > reclaiming.
> > >                          */
> > > -                       if (inactive_anon_is_low(zone, &sc))
> > > +                       if (scanning_global_lru(&sc) &&
> > > +                                       inactive_anon_is_low(zone, &sc))
> > >                                 shrink_active_list(SWAP_CLUSTER_MAX, zone,
> > >                                                         &sc, priority, 0);
> >
> > Thanks!  I completely overlooked this one and only noticed it after
> > changing the arguments to shrink_active_list().
> >
> > On memcg configurations, scanning_global_lru() will essentially never
> > be true again, so I moved the anon pre-aging to a separate function
> > that also does a hierarchy loop to preage the per-memcg anon lists.
> >
> > I hope to send out the next revision soon.
> 
> Also, please consider to fold in the following patch as well. It fixes
> the root cgroup lru accounting and we could easily trigger OOM while
> doing some swapoff test w/o it.

This makes perfect sense.  I'll incorporate this and add your
sign-offs to the original patch.  Thanks very to the both of you and
sorry for the inconvenience.
--
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/