From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, davej@redhat.com, ben@decadent.org.uk,
a.p.zijlstra@chello.nl, pjt@google.com, lennart@poettering.net,
kay.sievers@vrfy.org
Subject: Re: [RFC 0/5] forced comounts for cgroups.
Date: Tue, 4 Sep 2012 14:46:02 -0700 [thread overview]
Message-ID: <20120904214602.GA9092@dhcp-172-17-108-109.mtv.corp.google.com> (raw)
In-Reply-To: <1346768300-10282-1-git-send-email-glommer@parallels.com>
Hello, Glauber.
On Tue, Sep 04, 2012 at 06:18:15PM +0400, Glauber Costa wrote:
> As we have been extensively discussing, the cost and pain points for cgroups
> come from many places. But at least one of those is the arbitrary nature of
> hierarchies. Many people, including at least Tejun and me would like this to go
> away altogether. Problem so far, is breaking compatiblity with existing setups
>
> I am proposing here a default-n Kconfig option that will guarantee that the cpu
> cgroups (for now) will be comounted. I started with them because the
> cpu/cpuacct division is clearly the worst offender. Also, the default-n is here
> so distributions will have time to adapt: Forcing this flag to be on without
> userspace changes will just lead to cgroups failing to mount, which we don't
> want.
>
> Although I've tested it and it works, I haven't compile-tested all possible
> config combinations. So this is mostly for your eyes. If this gets traction,
> I'll submit it properly, along with any changes that you might require.
As I said during the discussion, I'm skeptical about how useful this
is. This can't nudge existing users in any meaningfully gradual way.
Kconfig doesn't make it any better. It's still an abrupt behavior
change when seen from userland.
Also, I really don't see much point in enforcing this almost arbitrary
grouping of controllers. It doesn't simplify anything and using
cpuacct in more granular way than cpu actually is one of the better
justified use of multiple hierarchies. Also, what about memcg and
blkcg? Do they *really* coincide? Note that both blkcg and memcg
involve non-trivial overhead and blkcg is essentially broken
hierarchy-wise.
Currently, from userland visible behavior POV, the crazy parts are
1. The flat hierarchy thing. This just should go away.
2. Orthogonal multiple hierarchies.
I think we agree that #1 should go away one way or the other. I
*really* wanna get rid of #2 but am not sure how. I'll give it
another stab once the writeback thing is resolved.
Thanks.
--
tejun
next prev parent reply other threads:[~2012-09-04 21:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 14:18 [RFC 0/5] forced comounts for cgroups Glauber Costa
2012-09-04 14:18 ` [RFC 1/5] cgroup: allow some comounts to be forced Glauber Costa
2012-09-04 14:18 ` [RFC 2/5] sched: adjust exec_clock to use it as cpu usage metric Glauber Costa
2012-09-04 14:18 ` [RFC 3/5] sched: do not call cpuacct_charge when cpu and cpuacct are comounted Glauber Costa
2012-09-04 14:18 ` [RFC 4/5] cpuacct: do not gather cpuacct statistics when not mounted Glauber Costa
2012-09-04 14:18 ` [RFC 5/5] sched: add cpusets to comounts list Glauber Costa
2012-09-04 21:46 ` Tejun Heo [this message]
2012-09-05 8:03 ` [RFC 0/5] forced comounts for cgroups Glauber Costa
2012-09-05 8:14 ` Tejun Heo
2012-09-05 8:17 ` Glauber Costa
2012-09-05 8:29 ` Tejun Heo
2012-09-05 8:35 ` Glauber Costa
2012-09-05 8:47 ` Tejun Heo
2012-09-05 8:55 ` Glauber Costa
2012-09-05 9:07 ` Tejun Heo
2012-09-05 9:06 ` Glauber Costa
2012-09-05 9:14 ` Tejun Heo
2012-09-05 9:06 ` Peter Zijlstra
2012-09-05 9:07 ` Peter Zijlstra
2012-09-05 9:22 ` Tejun Heo
2012-09-05 9:11 ` Tejun Heo
2012-09-05 9:12 ` Glauber Costa
2012-09-05 9:19 ` Tejun Heo
2012-09-05 9:30 ` Glauber Costa
2012-09-05 9:26 ` Peter Zijlstra
2012-09-05 9:31 ` Glauber Costa
2012-09-05 9:45 ` Tejun Heo
2012-09-05 9:48 ` Glauber Costa
2012-09-05 9:56 ` Tejun Heo
2012-09-05 10:20 ` Peter Zijlstra
2012-09-06 20:38 ` Tejun Heo
2012-09-06 22:39 ` Glauber Costa
2012-09-06 22:45 ` Tejun Heo
2012-09-05 9:32 ` Tejun Heo
2012-09-05 10:04 ` Peter Zijlstra
2012-09-06 20:46 ` Tejun Heo
2012-09-06 21:11 ` Paul Turner
2012-09-06 22:36 ` Glauber Costa
2012-09-08 13:36 ` Dhaval Giani
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=20120904214602.GA9092@dhcp-172-17-108-109.mtv.corp.google.com \
--to=tj@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=ben@decadent.org.uk \
--cc=cgroups@vger.kernel.org \
--cc=davej@redhat.com \
--cc=glommer@parallels.com \
--cc=kay.sievers@vrfy.org \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pjt@google.com \
/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).