[RFC PATCH] vmscan: memcg: Always use swappiness of the reclaimed memcg swappiness and oom_control

[Michal Hocko]

On Thu 24-04-14 08:19:17, Johannes Weiner wrote:
> 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.

OK, I originally thought this would be in the same patch but now that I
think about it some more it would be better to have it separate in case
it turns out this will cause some issues (at least
global_reclaim-always-use-global-vm_swappiness is a behavior change).
So what do you think about this?
---