linux-kernel - Re: [PATCH 1/4] memcg, mm: introduce lowlimit 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-next>] [day] [month] [year] [list]

Date:	Tue, 6 May 2014 16:32:42 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Greg Thelen <gthelen@...gle.com>,
	Michel Lespinasse <walken@...gle.com>,
	Tejun Heo <tj@...nel.org>, Hugh Dickins <hughd@...gle.com>,
	Roman Gushchin <klamm@...dex-team.ru>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH 1/4] memcg, mm: introduce lowlimit reclaim

On Tue 06-05-14 09:29:32, Johannes Weiner wrote:
> On Fri, May 02, 2014 at 06:00:56PM -0400, Johannes Weiner wrote:
> > On Fri, May 02, 2014 at 06:49:30PM +0200, Michal Hocko wrote:
> > > On Fri 02-05-14 11:58:05, Johannes Weiner wrote:
> > > > This is not even guarantees anymore, but rather another reclaim
> > > > prioritization scheme with best-effort semantics.  That went over
> > > > horribly with soft limits, and I don't want to repeat this.
> > > > 
> > > > Overcommitting on guarantees makes no sense, and you even agree you
> > > > are not interested in it.  We also agree that we can always add a knob
> > > > later on to change semantics when an actual usecase presents itself,
> > > > so why not start with the clear and simple semantics, and the simpler
> > > > implementation?
> > > 
> > > So you are really preferring an OOM instead? That was the original
> > > implementation posted at the end of last year and some people
> > > had concerns about it. This is the primary reason I came up with a
> > > weaker version which fallbacks rather than OOM.
> > 
> > I'll dig through the archives on this then, thanks.
> 
> The most recent discussion on this I could find was between you and
> Greg, where the final outcome was (excerpt):
> 
> ---
> 
> From: Greg Thelen <gthelen@...gle.com>
> To: Michal Hocko <mhocko@...e.cz>
> Cc: linux-mm@...ck.org,  Johannes Weiner <hannes@...xchg.org>,  Andrew Morton <akpm@...ux-foundation.org>,  KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,  LKML <linux-kernel@...r.kernel.org>,  Ying Han <yinghan@...gle.com>,  Hugh Dickins <hughd@...gle.com>,  Michel Lespinasse <walken@...gle.com>,  KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,  Tejun Heo <tj@...nel.org>
> Subject: Re: [RFC 0/4] memcg: Low-limit reclaim
> References: <1386771355-21805-1-git-send-email-mhocko@...e.cz>
> 	<xr93sis6obb5.fsf@...elen.mtv.corp.google.com>
> 	<20140130123044.GB13509@...p22.suse.cz>
> 	<xr931tzphu50.fsf@...elen.mtv.corp.google.com>
> 	<20140203144341.GI2495@...p22.suse.cz>
> Date: Mon, 03 Feb 2014 17:33:13 -0800
> Message-ID: <xr93zjm7br1i.fsf@...elen.mtv.corp.google.com>
> List-ID: <linux-mm.kvack.org>
> 
> On Mon, Feb 03 2014, Michal Hocko wrote:
> 
> > On Thu 30-01-14 16:28:27, Greg Thelen wrote:
> >> But this soft_limit,priority extension can be added later.
> >
> > Yes, I would like to have the strong semantic first and then deal with a
> > weaker form. Either by a new limit or a flag.
> 
> Sounds good.
> 
> ---
> 
> So I think everybody involved in the discussions so far are preferring
> a hard guarantee, and then later, if needed, to either add a knob to
> make it a soft guarantee or to actually implement a usable soft limit.

I am afraid the most of that discussion happened off-list :( Sadly not
much of a discussion happened on the list.
Sorry I should have been specific and mention that the discussions
happened at LSF and partly at the KS.

The strongest point was made by Rik when he claimed that memcg is not
aware of memory zones and so one memcg with lowlimit larger than the
size of a zone can eat up that zone without any way to free it. This
can cause additional troubles (permanent reclaim on that zone and OOM in
an extreme situations).

That convinced me that having the default oom semantic from the very
beginning is too much and starting with something more relaxed (fallback
rather than oom), but still usable, is a better choice.
-- 
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/