linux-kernel - Re: [PATCH] update sc->nr_reclaimed after each shrink

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: <20160722081259.GE26049@esperanza>
Date:	Fri, 22 Jul 2016 11:12:59 +0300
From:	Vladimir Davydov <vdavydov@...tuozzo.com>
To:	Michal Hocko <mhocko@...nel.org>
CC:	Zhou Chengming <zhouchengming1@...wei.com>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<akpm@...ux-foundation.org>, <riel@...hat.com>,
	<guohanjun@...wei.com>
Subject: Re: [PATCH] update sc->nr_reclaimed after each shrink_slab

On Fri, Jul 22, 2016 at 09:49:13AM +0200, Michal Hocko wrote:
> On Fri 22-07-16 11:43:30, Zhou Chengming wrote:
> > In !global_reclaim(sc) case, we should update sc->nr_reclaimed after each
> > shrink_slab in the loop. Because we need the correct sc->nr_reclaimed
> > value to see if we can break out.
> 
> Does this actually change anything? Maybe I am missing something but
> try_to_free_mem_cgroup_pages which is the main entry for the memcg
> reclaim doesn't set reclaim_state. I don't remember why... Vladimir?

We don't set reclaim_state on memcg reclaim, because there might be a
lot of unrelated slab objects freed from the interrupt context (e.g.
RCU freed) while we're doing memcg reclaim. Obviously, we don't want
them to contribute to nr_reclaimed.

Link to the thread with the problem discussion:

  http://marc.info/?l=linux-kernel&m=142132698209680&w=2