From: Glauber Costa <glommer@parallels.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Daniel Walsh <dwalsh@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Li Zefan <lizf@cn.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg
Date: Thu, 12 Apr 2012 10:12:29 -0300 [thread overview]
Message-ID: <4F86D4BD.1040305@parallels.com> (raw)
In-Reply-To: <20120412123256.GI1787@cmpxchg.org>
On 04/12/2012 09:32 AM, Johannes Weiner wrote:
> On Thu, Apr 12, 2012 at 08:43:02AM -0300, Glauber Costa wrote:
>> On 04/12/2012 08:32 AM, Frederic Weisbecker wrote:
>>>> But I think increasing number of subsystem is not very good....
>>> If the result is a better granularity on the overhead, I believe this
>>> can be a good thing.
>>
>> But again, since there is quite number of people trying to merge
>> those stuff together, you are just swimming against the tide.
>
> I don't see where merging unrelated controllers together is being
> discussed, do you have a reference?
https://lkml.org/lkml/2012/2/21/379
But also, I believe this has been widely discussed in person by people,
in separate groups. Maybe Tejun can do a small writeup of where we stand?
I would also point out that this is exactly what it is (IMHO): an
ongoing discussion. You are more than welcome to chime in.
>> If this gets really integrated, out of a sudden the overhead will
>> appear. So better care about it now.
>
> Forcing people that want to account/limit one resource to take the hit
> for something else they are not interested in requires justification.
Agree. Even people aiming for unified hierarchies are okay with an
opt-in/out system, I believe. So the controllers need not to be active
at all times. One way of doing this is what I suggested to Frederic: If
you don't limit, don't account.
> You can optimize only so much, in the end, the hierarchical accounting
> is just expensive and unacceptable if you don't care about a certain
> resource. For that reason, I think controllers should stay opt-in.
see above.
> Btw, can we please have a discussion where raised concerns are
> supported by more than gut feeling? "I think X is not very good" is
> hardly an argument. Where is the technical problem in increasing the
> number of available controllers?
Kame said that, not me. But FWIW, I don't disagree. And this is hardly
gut feeling.
A big number of controllers creates complexity. When coding, we can
assume a lot less things about their relationships, and more
importantly: at some point people get confused. Fuck, sometimes *we* get
confused about which controller do what, where its responsibility end
and where the other's begin. And we're the ones writing it! Avoiding
complexity is an engineering principle, not a gut feeling.
Now, of course, we should aim to make things as simple as possible, but
not simpler: So you can argue that in Frederic's specific case, it is
justified. And I'd be fine with that 100 %. If I agreed...
There are two natural points for inclusion here:
1) every cgroup has a task counter by itself. If we're putting the tasks
there anyway, this provides a natural point of accounting.
2) The cpu cgroup, in the end, is the realm of the scheduler. We
determine which % of the cpu the process will get, bandwidth, time spent
by tasks, and all that. It is also more natural for that, because it is
task based.
Don't get me wrong: I actually love the feature Frederic is working on.
I just don't believe a different controller is justified. Nor do I
believe memcg is the place for that (specially now that I thought it
overnight)
next prev parent reply other threads:[~2012-04-12 13:14 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 18:57 [RFD] Merge task counter into memcg Frederic Weisbecker
2012-04-11 19:21 ` Glauber Costa
2012-04-12 11:19 ` Frederic Weisbecker
2012-04-12 0:56 ` KAMEZAWA Hiroyuki
2012-04-12 11:32 ` Frederic Weisbecker
2012-04-12 11:43 ` Glauber Costa
2012-04-12 12:32 ` Johannes Weiner
2012-04-12 13:12 ` Glauber Costa [this message]
2012-04-12 15:30 ` Johannes Weiner
2012-04-12 16:38 ` Tejun Heo
2012-04-12 17:04 ` Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter into memcg) Glauber Costa
2012-04-17 15:13 ` Tejun Heo
2012-04-17 15:27 ` Glauber Costa
2012-04-12 17:13 ` [RFD] Merge task counter into memcg Glauber Costa
2012-04-12 17:23 ` Johannes Weiner
2012-04-12 17:41 ` Tejun Heo
2012-04-12 17:53 ` Glauber Costa
2012-04-13 1:42 ` KAMEZAWA Hiroyuki
2012-04-13 1:50 ` Glauber Costa
2012-04-13 2:48 ` KAMEZAWA Hiroyuki
2012-04-17 15:41 ` Tejun Heo
2012-04-17 16:52 ` Glauber Costa
2012-04-18 6:51 ` KAMEZAWA Hiroyuki
2012-04-18 7:53 ` Frederic Weisbecker
2012-04-18 8:42 ` KAMEZAWA Hiroyuki
2012-04-18 9:12 ` Frederic Weisbecker
2012-04-18 10:39 ` Johannes Weiner
2012-04-18 11:00 ` KAMEZAWA Hiroyuki
2012-04-12 16:54 ` Glauber Costa
2012-04-12 1:07 ` Johannes Weiner
2012-04-12 2:15 ` Glauber Costa
2012-04-12 3:26 ` Li Zefan
2012-04-12 14:55 ` Frederic Weisbecker
2012-04-12 16:34 ` Glauber Costa
2012-04-12 16:59 ` Frederic Weisbecker
2012-04-17 15:17 ` Tejun Heo
2012-04-18 6:54 ` Frederic Weisbecker
2012-04-18 8:10 ` Frederic Weisbecker
2012-04-18 12:00 ` Glauber Costa
2012-04-12 4:00 ` Alexander Nikiforov
[not found] ` <4F86527C.2080507@samsung.com>
2012-04-17 1:09 ` Frederic Weisbecker
2012-04-17 6:45 ` Alexander Nikiforov
2012-04-17 15:23 ` Tejun Heo
2012-04-19 3:34 ` Alexander Nikiforov
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=4F86D4BD.1040305@parallels.com \
--to=glommer@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=berrange@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=dwalsh@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=tj@kernel.org \
/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).