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:
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.
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??
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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>