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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150113074633.GG2110@esperanza>
Date:	Tue, 13 Jan 2015 10:46:33 +0300
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Johannes Weiner <hannes@...xchg.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.cz>,
	Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...e.de>,
	Rik van Riel <riel@...hat.com>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm 1/2] mm: vmscan: account slab pages on memcg reclaim

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@...allels.com>
> > ---
> >  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 *@..._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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/