linux-kernel - Re: [patch v4] Soft limit rework

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: <20130604163828.GA9321@dhcp22.suse.cz>
Date:	Tue, 4 Jun 2013 18:38:28 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Balbir Singh <bsingharora@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm <linux-mm@...ck.org>,
	"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ying Han <yinghan@...gle.com>, Hugh Dickins <hughd@...gle.com>,
	Glauber Costa <glommer@...allels.com>,
	Michel Lespinasse <walken@...gle.com>,
	Greg Thelen <gthelen@...gle.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [patch v4] Soft limit rework

On Tue 04-06-13 21:57:56, Balbir Singh wrote:
> On Mon, Jun 3, 2013 at 3:48 PM, Michal Hocko <mhocko@...e.cz> wrote:
> > Hi,
> >
> > This is the fourth version of the patchset.
> >
> > Summary of versions:
> > The first version has been posted here: http://permalink.gmane.org/gmane.linux.kernel.mm/97973
> > (lkml wasn't CCed at the time so I cannot find it in lwn.net
> > archives). There were no major objections. The second version
> > has been posted here http://lwn.net/Articles/548191/ as a part
> > of a longer and spicier thread which started after LSF here:
> > https://lwn.net/Articles/548192/
> > Version number 3 has been posted here http://lwn.net/Articles/550409/
> > Johannes was worried about setups with thousands of memcgs and the
> > tree walk overhead for the soft reclaim pass without anybody in excess.
> >
> > Changes between RFC (aka V1) -> V2
> > As there were no major objections there were only some minor cleanups
> > since the last version and I have moved "memcg: Ignore soft limit until
> > it is explicitly specified" to the end of the series.
> >
> > Changes between V2 -> V3
> > No changes in the code since the last version. I have just rebased the
> > series on top of the current mmotm tree. The most controversial part
> > has been dropped (the last patch "memcg: Ignore soft limit until it is
> > explicitly specified") so there are no semantical changes to the soft
> > limit behavior. This makes this work mostly a code clean up and code
> > reorganization. Nevertheless, this is enough to make the soft limit work
> > more efficiently according to my testing and groups above the soft limit
> > are reclaimed much less as a result.
> >
> > Changes between V3->V4
> > Added some Reviewed-bys but the biggest change comes from Johannes
> > concern about the tree traversal overhead with a huge number of memcgs
> > (http://thread.gmane.org/gmane.linux.kernel.cgroups/7307/focus=100326)
> > and this version addresses this problem by augmenting the memcg tree
> > with the number of over soft limit children at each level of the
> > hierarchy. See more bellow.
> >
> > The basic idea is quite simple. Pull soft reclaim into shrink_zone in
> > the first step and get rid of the previous soft reclaim infrastructure.
> > shrink_zone is done in two passes now. First it tries to do the soft
> > limit reclaim and it falls back to reclaim-all mode if no group is over
> > the limit or no pages have been scanned. The second pass happens at the
> > same priority so the only time we waste is the memcg tree walk which
> > has been updated in the third step to have only negligible overhead.
> >
> 
> Hi, Michal
> 
> I've just looked at this (I am yet to review the series), but the
> intention of the changes do not read out clearly. Or may be I quite
> outdated on the subject :)

OK, let me summarize. The primary intention is to get rid of the current
soft reclaim infrastructure which basically bypasses the standard
reclaim and tight it directly into shrink_zone code. This also means
that the soft reclaim doesn't reclaim at priority 0 and that it is
active also for the targeted (aka limit) reclaim.

Does this help?
 
> Balbir

-- 
Michal Hocko
SUSE Labs
--
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/