From: Glauber Costa <email@example.com> To: Tejun Heo <firstname.lastname@example.org> Cc: <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Subject: Re: [RFC 0/5] forced comounts for cgroups. Date: Wed, 5 Sep 2012 12:55:21 +0400 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20120905084740.GE3195@dhcp-172-17-108-109.mtv.corp.google.com> On 09/05/2012 12:47 PM, Tejun Heo wrote: > Hello, Glauber. > > On Wed, Sep 05, 2012 at 12:35:11PM +0400, Glauber Costa wrote: >>> As long as cpuacct and cpu are separate, I think it makes sense to >>> assume that they at least could be at different granularity. >> >> If they are comounted, and more: forceably comounted, I don't see how to >> call them separate. At the very best, they are this way for >> compatibility purposes only, to lay a path that would allow us to get >> rid of the separation eventually. > > I think this is where we disagree. I didn't mean that all controllers > should be using exactly the same hierarchy when I was talking about > unified hierarchy. I do think it's useful and maybe even essential to > allow differing levels of granularity. cpu and cpuacct could be a > valid example for this. Likely blkcg and memcg too. > > So, I think it's desirable for all controllers to be able to handle > hierarchies the same way and to have the ability to tag something as > belonging to certain group in the hierarchy for all controllers but I > don't think it's desirable or feasible to require all of them to > follow exactly the same grouping at all levels. > By "different levels of granularity" do you mean having just a subset of them turned on at a particular place? If yes, having them guaranteed to be comounted is still perceived by me as a good first step. A natural following would be to turn them on/off on a per-group basis.
next prev parent reply other threads:[~2012-09-05 8:58 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-04 14:18 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 ` [RFC 0/5] forced comounts for cgroups Tejun Heo 2012-09-05 8:03 ` 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 [this message] 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC 0/5] forced comounts for cgroups.' \ /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
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).