On 06/27/2012 02:14 AM, Tejun Heo wrote:

Hello, Michal.

On Wed, Jun 27, 2012 at 12:08:09AM +0200, Michal Hocko wrote:

quoted

According to my experience, people usually create deeper subtrees
just because they want to have memcg hierarchy together with other
controller(s) and the other controller requires a different topology
but then they do not care about memory.* attributes in parents.
Those cases are not affected by this change because parents are
unlimited by default.
Deeper subtrees without hierarchy and independent limits are usually
mis-configurations, and we would like to hear about those to help to fix
them, or they are unfixable usecases which we want to know about as well
(because then we have a blocker for the unified cgroup hierarchy, don't
we).

Yeah, this is something I'm seriously considering doing from cgroup
core.  ie. generating a warning message if the user nests cgroups w/
controllers which don't support full hierarchy.

quoted

quoted

   Note that the default should still be flat hierarchy.

2. Mark flat hierarchy deprecated and produce a warning message if
    memcg is mounted w/o hierarchy option for a year or two.

I would agree with you on this with many kernel configurables but
this one doesn't fall in. There is a trivial fallback (set root to
use_hierarchy=0) so the mount option seems like an overkill - yet
another API to keep for some time...

Just disallow clearing .use_hierarchy if it was mounted with the
option?  We can later either make the file RO 1 for compatibility's
sake or remove it.

How will it buy us anything, if it is clear by default??

quoted

So in short, I do think we should go the sanity path and end up
with hierarchical trees and sooner we start the better.

I do agree with you in principle, but I still don't think we can
switch the default behavior underneath the users.

I think we all agree with that. I can't speak for Johannes here, but I 
risk saying that he agrees with that as well.

The problem is that we may differ in what means "default behavior".

It is very clear in a system call, API, or any documented feature. We 
never made the guarantee, *ever*, that non-hierarchical might be the 
default.

I understand that users may have grown accustomed to it. But users grow 
accustomed to bugs as well! Bugs change behaviors. In fact, in hardware 
emulation - where it matters, because it is harder to change it - we 
have emulator people actually emulating bugs - because that is what 
software expects.

Is this reason for us to keep bugs around, because people grew 
accustomed to it? Hell no. Well, it might be: If we have a proven user 
base that is big and solid on top of that, it may be fair to say: "Well, 
this is unfortunate, but this is how it plays".

Here, we're discussing - or handwaving as Hannes stated, about whether 
or not we have *some* users relying on this behavior. We must certainly 
agree that this is not by far a solid and big usersbase, or anything at 
the like.

Another analogy I believe it is pertinent: I consider this change much 
closer to icon or button placement in the Desktop market: No one *ever* 
said a particular button stays at a particular place. Yet it was there 
for many releases. If you change it, some people will feel it. So what?
People change it anyway. Because that is *not* anything set in stone.



--
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>