From: Michal Hocko <mhocko@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: memcontrol: remove hierarchy restrictions for swappiness and oom_control
Date: Fri, 18 Apr 2014 13:36:11 +0200 [thread overview]
Message-ID: <20140418113611.GA7568@dhcp22.suse.cz> (raw)
In-Reply-To: <1397682798-22906-1-git-send-email-hannes@cmpxchg.org>
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.
> 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.
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-04-18 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 21:13 [patch] mm: memcontrol: remove hierarchy restrictions for swappiness and oom_control Johannes Weiner
2014-04-16 21:34 ` Andrew Morton
2014-04-17 12:56 ` Johannes Weiner
2014-04-18 11:36 ` Michal Hocko [this message]
2014-04-24 12:19 ` Johannes Weiner
2014-04-24 14:27 ` [RFC PATCH] vmscan: memcg: Always use swappiness of the reclaimed memcg " Michal Hocko
2014-04-30 9:09 ` Michal Hocko
2014-04-30 23:06 ` Johannes Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140418113611.GA7568@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).