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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Glauber.

On Wed, Jun 27, 2012 at 12:52:27PM +0400, Glauber Costa wrote:
> >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

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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]