linux-kernel - Re: [PATCH v2 0/4] memcg: Low-limit 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: <20140429125457.GG15058@dhcp22.suse.cz>
Date:	Tue, 29 Apr 2014 14:54:57 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Roman Gushchin <klamm@...dex-team.ru>
Cc:	Greg Thelen <gthelen@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Michel Lespinasse <walken@...gle.com>,
	Tejun Heo <tj@...nel.org>, Hugh Dickins <hughd@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v2 0/4] memcg: Low-limit reclaim

On Tue 29-04-14 14:50:18, Roman Gushchin wrote:
> 29.04.2014, 11:42, "Greg Thelen" <gthelen@...gle.com>:
> > On Mon, Apr 28 2014, Roman Gushchin <klamm@...dex-team.ru> wrote:
> >
> >>  28.04.2014, 16:27, "Michal Hocko" <mhocko@...e.cz>:
> >>>  The series is based on top of the current mmotm tree. Once the series
> >>>  gets accepted I will post a patch which will mark the soft limit as
> >>>  deprecated with a note that it will be eventually dropped. Let me know
> >>>  if you would prefer to have such a patch a part of the series.
> >>>
> >>>  Thoughts?
> >>  Looks good to me.
> >>
> >>  The only question is: are there any ideas how the hierarchy support
> >>  will be used in this case in practice?
> >>  Will someone set low limit for non-leaf cgroups? Why?
> >>
> >>  Thanks,
> >>  Roman
> >
> > I imagine that a hosting service may want to give X MB to a top level
> > memcg (/a) with sub-jobs (/a/b, /a/c) which may(not) have their own
> > low-limits.

I would expect the limit would be set on leaf nodes most of the time
because intermediate nodes have charges inter-mixed with charges from
children so it is not entirely clear who to protect.
On the on the other hand I can imagine that the higher level node might
get some portion of memory by an admin without any way to set the limit
down the hierarchy for its user as described by Greg.

> > Examples:
> >
> > case_1) only set low limit on /a.  /a/b and /a/c may overcommit /a's
> >         memory (b.limit_in_bytes + c.limit_in_bytes > a.limit_in_bytes).
> >
> > case_2) low limits on all memcg.  But not overcommitting low_limits
> >         (b.low_limit_in_in_bytes + c.low_limit_in_in_bytes <=
> >         a.low_limit_in_in_bytes).
> 
> Thanks!
> 
> With use_hierarchy turned on it looks perfectly usable.

use_hierarchy is becoming the default and we even complain about deeper
directory structures without it being enabled.

-- 
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/