Re: [PATCH -mm 1/2] mm: vmscan: account slab pages on memcg reclaim

[Vladimir Davydov]

On Mon, Jan 12, 2015 at 05:18:39PM -0500, Johannes Weiner wrote:
> On Mon, Jan 12, 2015 at 12:30:37PM +0300, Vladimir Davydov wrote:
> > Since try_to_free_mem_cgroup_pages() can now call slab shrinkers, we
> > should initialize reclaim_state and account reclaimed slab pages in
> > scan_control->nr_reclaimed.
> > 
> > Signed-off-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>
> > ---
> >  mm/vmscan.c |   33 ++++++++++++++++++++++-----------
> >  1 file changed, 22 insertions(+), 11 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 16f3e45742d6..b2c041139a51 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -367,13 +367,16 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
> >   * the ->seeks setting of the shrink function, which indicates the
> >   * cost to recreate an object relative to that of an LRU page.
> >   *
> > - * Returns the number of reclaimed slab objects.
> > + * Returns the number of reclaimed slab objects. The number of reclaimed
> > + * pages is added to *@ret_nr_reclaimed.
> >
> >  static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
> >  				 struct mem_cgroup *memcg,
> >  				 unsigned long nr_scanned,
> > -				 unsigned long nr_eligible)
> > +				 unsigned long nr_eligible,
> > +				 unsigned long *ret_nr_reclaimed)
> 
> Can't we just return the number of pages directly from this function?

Hmm, we can. That would look better, of course. However, reclaimed_slab
can be 0 even if we reclaimed tons of dentries/inodes, simply because
they are freed by rcu. In this case, we can abort drop_slab beforehand.
Do you think it's OK?

Thanks,
Vladimir

> 
> > @@ -426,7 +434,7 @@ void drop_slab_node(int nid)
> >  		freed = 0;
> >  		do {
> >  			freed += shrink_slab(GFP_KERNEL, nid, memcg,
> > -					     1000, 1000);
> > +					     1000, 1000, &nr_reclaimed);
> >  		} while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> >  	} while (freed > 10);
> 
> This is the only caller that cares about the return value, and it's a
> magic number that could probably be changed to comparing with a magic
> number of pages instead.
--
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/