Re: memcg: softlimit on internal nodes

[Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>]

On Mon 22-04-13 08:46:20, Tejun Heo wrote:
> Hey, Michal.
> 
> On Mon, Apr 22, 2013 at 05:37:30PM +0200, Michal Hocko wrote:
> > > In fact, I'm planning to disallow changing ownership of cgroup files
> > > when "sane_behavior" is specified. 
> > 
> > I would be wildly oposing this. Enabling user to play on its own ground
> > while above levels of the groups enforce the reasonable behavior is very
> > important use case.
> 
> We can continue this discussion on the original thread and I'm not too
> firm on this not because it's a sane use case but because it is an
> extra measure preventing root from shooting its feet which we
> traditionally allow.  That said, really, no good can come from
> delegating hierarchy to different security domains.  It's already
> discouraged by the userland best practices doc.  Just don't do it.

OK, I will go to the original mail thread and discuss my concerns there.

> > Tejun, stop this, finally! Current soft limit same as the reworked
> > version follow the basic nesting rule we use for the hard limit which
> > says that parent setting is always more strict than its children.
> > So if you parent says you are hitting the hardlimit (resp. over soft
> > limit) then children are reclaimed regardless their hard/soft limit
> > setting.
> 
> Okay, thanks for making it clear.  Then, apparently, the fine folks at
> google are hopelessly confused because at least Greg and Ying told me
> something which is the completely opposite of what you're saying.  You
> guys need to sort it out.
> 
> > It is you being confused and refuse to open the damn documentation and
> > read what the hack is soft limit and what it is used for. Read the patch
> > series I was talking about and you will hardly find anything regarding
> > _guarantee_.
> 
> 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) you can actually achieve
_high_ probability for not being reclaimed after the rework which was not
possible before because of the implementation which was ugly and
smelled.

> 
> Thanks.
> 
> -- 
> tejun

-- 
Michal Hocko
SUSE Labs