linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: Michal Hocko <mhocko@suse.cz>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	kamezawa.hiroyu@jp.fujitsu.com,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/2] memcg: first step towards hierarchical controller
Date: Wed, 27 Jun 2012 09:58:41 -0700	[thread overview]
Message-ID: <20120627165841.GH15811@google.com> (raw)
In-Reply-To: <4FEAC9CB.2010800@parallels.com>

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

  reply	other threads:[~2012-06-27 16:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 15:47 [PATCH 0/2] fix and deprecate use_hierarchy file Glauber Costa
2012-06-26 15:47 ` [PATCH 1/2] fix bad behavior in " Glauber Costa
2012-06-26 15:52   ` Michal Hocko
2012-06-26 15:54   ` Johannes Weiner
2012-06-26 22:25   ` Andrew Morton
2012-06-26 22:30     ` Tejun Heo
2012-06-26 15:47 ` [PATCH 2/2] memcg: first step towards hierarchical controller Glauber Costa
2012-06-26 16:15   ` Michal Hocko
2012-06-26 16:37     ` Glauber Costa
2012-06-26 17:54       ` Michal Hocko
2012-06-26 18:04   ` Tejun Heo
2012-06-26 18:55     ` Johannes Weiner
2012-06-26 19:14       ` Tejun Heo
2012-06-26 20:59         ` Johannes Weiner
2012-06-26 21:19           ` Tejun Heo
2012-06-27  8:57             ` Glauber Costa
2012-06-27 17:07               ` Tejun Heo
2012-06-26 22:08     ` Michal Hocko
2012-06-26 22:14       ` Tejun Heo
2012-06-26 22:17         ` Tejun Heo
2012-06-27  8:52         ` Glauber Costa
2012-06-27 16:58           ` Tejun Heo [this message]
2012-06-27 12:51         ` Michal Hocko
2012-06-27 12:49           ` Glauber Costa
2012-06-27 17:33           ` Tejun Heo
2012-06-28  8:46             ` Kamezawa Hiroyuki
2012-06-28  9:12               ` Glauber Costa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120627165841.GH15811@google.com \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=glommer@parallels.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).