linux-kernel - Re: [patch] mm: memcontrol: remove hierarchy restrictions for swappiness and oom

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: <20140424121917.GB4107@cmpxchg.org>
Date:	Thu, 24 Apr 2014 08:19:17 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] mm: memcontrol: remove hierarchy restrictions for
 swappiness and oom_control

On Fri, Apr 18, 2014 at 01:36:11PM +0200, Michal Hocko wrote:
> On Wed 16-04-14 17:13:18, Johannes Weiner wrote:
> > Per-memcg swappiness and oom killing can currently not be tweaked on a
> > memcg that is part of a hierarchy, but not the root of that hierarchy.
> > Users have complained that they can't configure this when they turned
> > on hierarchy mode.  In fact, with hierarchy mode becoming the default,
> > this restriction disables the tunables entirely.
> 
> Except when we would handle the first level under root differently,
> which is ugly.
> 
> > But there is no good reason for this restriction. 
> 
> I had a patch for this somewhere on the think_more pile. I wasn't
> particularly happy about the semantic so I haven't posted it.
> 
> > The settings for
> > swappiness and OOM killing are taken from whatever memcg whose limit
> > triggered reclaim and OOM invocation, regardless of its position in
> > the hierarchy tree.
> 
> This is OK for the OOM knob because the memory pressure cannot be
> handled at that level in hierarchy and that is where the OOM happens.
> 
> I am not so sure about the swappiness though. The swappiness tells us
> how to proportionally scan anon vs. file LRUs and those are per-memcg,
> not per-hierarchy (unlike the charge) so it makes sense to use it
> per-memcg IMO.
> 
> Besides that using the reclaim target value might be quite confusing.
> Say, somebody wants to prevent from swapping in a certain group and
> yet the pages find their way to swap depending on where the reclaim is
> triggered from.
> Another thing would be that setting swappiness on an unlimited group has
> no effect although I would argue it makes some sense in configuration
> when parent is controlled by somebody else. I would like to tell how
> to reclaim me when I cannot say how much memory I can have. 
> 
> It is true that we have a different behavior for the global reclaim
> already but I am not entirely happy about that. Having a different
> behavior for the global vs. limit reclaims just calls for troubles and
> should be avoided as much as possible.
> 
> So let's think what is the best semantic before we merge this. I would
> be more inclined for using per-memcg swappiness all the time (root using
> the global knob) for all reclaims.

Yeah, we've always used the triggering group's swappiness value but at
the same time forced the whole hierarchy to have the same setting as
the root.

I don't really feel strongly about this.  If you prefer the per-memcg
swappiness I can send a followup patch - or you can.

> > Allow setting swappiness on any group.  The knob on the root memcg
> > already reads the global VM swappiness, make it writable as well.
> 
> I am OK with the change but I think we should discuss the semantic
> first.

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