Thread (27 messages) 27 messages, 6 authors, 2012-06-28

Re: [PATCH 2/2] memcg: first step towards hierarchical controller

From: Tejun Heo <hidden>
Date: 2012-06-27 16:58:46
Also in: linux-mm

Hello, Glauber.

On Wed, Jun 27, 2012 at 12:52:27PM +0400, Glauber Costa wrote:
quoted
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??
With the mount option specified, why would it be clear by default?
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".
You're just playing with semantics now.  Hey, who guarantees anything?
I don't find anything inscribed in stone or with hundred goverment
stamps which legally forbids me from "rm -rf"ing the whole cgroup.

Gees...  If we've shipped kernel versions with certain major behavior
for years, that frigging is the guarantee we've been making to the
userland.

Of course, nothing is absolute and everything is subject to trade off,
but, come on, we're talking about major SILENT behavior switch.  No,
nobody gets away with that.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help