Re: memcg: softlimit on internal nodes

[Michal Hocko <mhocko@suse.cz>]

On Tue 23-04-13 14:17:22, Glauber Costa wrote:
> On 04/23/2013 01:58 PM, Michel Lespinasse wrote:
> > On Mon, Apr 22, 2013 at 8:54 AM, Michal Hocko <mhocko@suse.cz> wrote:
> >> On Mon 22-04-13 08:46:20, Tejun Heo wrote:
> >>> Oh, if so, I'm happy.  Sorry about being brash on the thread; however,
> >>> please talk with google memcg people.  They have very different
> >>> interpretation of what "softlimit" is and are using it according to
> >>> that interpretation.  If it *is* an actual soft limit, there is no
> >>> inherent isolation coming from it and that should be clear to
> >>> everyone.
> >>
> >> We have discussed that for a long time. I will not speak for Greg & Ying
> >> but from my POV we have agreed that the current implementation will work
> >> for them with some (minor) changes in their layout.
> >> As I have said already with a careful configuration (e.i. setting the
> >> soft limit only where it matters - where it protects an important
> >> memory which is usually in the leaf nodes)
> > 
> > I don't like your argument that soft limits work if you only set them
> > on leaves. To me this is just a fancy way of saying that hierarchical
> > soft limits don't work.
> > 
> > Also it is somewhat problematic to assume that important memory can
> > easily be placed in leaves. This is difficult to ensure when
> > subcontainer destruction, for example, moves the memory back into the
> > parent.
> > 
> 
> Michal,
> 
> For the most part, I am siding with you in this discussion.
> But with this only-in-leaves thing, I am forced to flip (at least for this).
> 
> You are right when you say that in a configuration with A being parent
> of B and C, A being over its hard limit will affect reclaim in B and C,
> and soft limits should work the same.
> 
> However, "will affect reclaim" is a big vague. More specifically, if the
> sum of B and C's hard limit is smaller or equal A's hard limit, the only
> way of either B or C to trigger A's hard limit is for them, themselves,
> to go over their hard limit.

Which is an expectation that you cannot guarantee. You can have B+C>A.

> *This* is the case you you are breaking when you try to establish a
> comparison between soft and hard limits - which is, per se, sane.
> 
> Translating this to the soft limit speech, if the sum of B and C's soft
> limit is smaller or equal A's soft limit, and one of them is over the
> soft limit, that one should be reclaimed. The other should be left alone.

And yet again. Nothing will prevent you from setting B+C>A. Sure if you
configure your hierarchy sanely then everything will just work.

> I understand perfectly fine that soft limit is a best effort, not a
> guarantee. But if we don't do that, I understand that we are doing
> effort, not best effort.
> 
> This would only be attempted in our first pass. In the second pass, we
> reclaim from whoever.
> 
> It is also not that hard to do it: Flatten the tree in a list, with the
> leaves always being placed before the inner nodes.

Glauber, I have already pointed out that bottom-up reclaim doesn't make
much sense because it is a bigger chance that useful data is stored in
the leaf nodes rather than inner nodes which usually contain mostly
reparented pages.

> Start reclaiming from nodes over the soft limit, hierarchically. This
> means that whenever we reach an inner node and it is *still* over
> the soft limit, we are guaranteed to have scanned their children
> already. In the case I described, the children over its soft limit
> would have been reclaimed, without the well behaving children being
> touched. Now all three are okay.
> 
> If we reached an inner node and we still have a soft limit problem, then
> we are effectively talking about the case you have been describing.
> Reclaim from whoever you want.
-- 
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>