From: Paul Turner <email@example.com> To: Tejun Heo <firstname.lastname@example.org> Cc: Peter Zijlstra <email@example.com>, Glauber Costa <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, Dhaval Giani <firstname.lastname@example.org>, Frederic Weisbecker <email@example.com> Subject: Re: [RFC 0/5] forced comounts for cgroups. Date: Thu, 6 Sep 2012 14:11:00 -0700 [thread overview] Message-ID: <CAPM31RKVYpkc0oTJKjsdsvqBfif=Bovi3a6TE8qdOOpEYOC0Lw@mail.gmail.com> (raw) In-Reply-To: <20120906204642.GN29092@google.com> On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo <firstname.lastname@example.org> wrote: > Hello, > > cc'ing Dhaval and Frederic. They were interested in the subject > before and Dhaval was pretty vocal about cpuacct having a separate > hierarchy (or at least granularity). Really? Time just has _not_ borne out this use-case. I'll let Dhaval make a case for this but he should expect violent objection. > > On Wed, Sep 05, 2012 at 12:04:47PM +0200, Peter Zijlstra wrote: >> > cpuacct is rather unique tho. I think it's gonna be silly whether the >> > hierarchy is unified or not. >> > >> > 1. If they always can live on the exact same hierarchy, there's no >> > point in having the two separate. Just merge them. >> > >> > 2. If they need differing levels of granularity, they either need to >> > do it completely separately as they do now or have some form of >> > dynamic optimization if absolutely necesary. >> > >> > So, I think that choice is rather separate from other issues. If >> > cpuacct is gonna be kept, I'd just keep it separate and warn that it >> > incurs extra overhead for the current users if for nothing else. >> > Otherwise, kill it or merge it into cpu. >> >> Quite, hence my 'proposal' to remove cpuacct. >> >> There was some whining last time Glauber proposed this, but the one >> whining never convinced and has gone away from Linux, so lets just do >> this. >> >> Lets make cpuacct print a deprecated msg to dmesg for a few releases and >> make cpu do all this. > > I like it. Currently cpuacct is the only problematic one in this > regard (cpuset to a much lesser extent) and it would be great to make > it go away. > > Dhaval, Frederic, Paul, if you guys object, please voice your > opinions. > >> The co-mounting stuff would have been nice for cpusets as well, knowing >> all your tasks are affine to a subset of cpus allows for a few >> optimizations (smaller cpumask iterations), but I guess we'll have to do >> that dynamically, we'll just have to see how ugly that is. > > Forced co-mounting sounds rather silly to me. If the two are always > gonna be co-mounted, why not just merge them and switch the > functionality depending on configuration? I'm fairly sure the code > would be simpler that way. It would be simpler but the problem is we'd break any userspace that was just doing mount cpuacct? Further, even if it were mounting both, userspace code still has to be changed to read from "cpu.export" instead of "cpuacct.export". I think a sane path on this front is: Immediately: Don't allow cpuacct and cpu to be co-mounted on separate hierarchies simultaneously. That is: mount none /dev/cgroup/cpuacct -t cgroupfs -o cpuacct : still works mount none /dev/cgroup/cpu -t cgroupfs -o cpu : still works mount none /dev/cgroup/cpux -t cgroupfs -o cpuacct,cpu : still works But the combination: mount none /dev/cgroup/cpu -t cgroupfs -o cpu : still works mount none /dev/cgroup/cpuacct -t cgroupfs -o cpu : EINVAL [or vice versa]. Also: WARN_ON when mounting cpuacct without cpu, strongly explaining that ANY such configuration is deprecated. Glauber's patchset goes most of the way towards enabling this. In a release or two: Make the restriction strict; don't allow individual mounting of cpuacct, force it to be mounted ONLY with cpu. Glauber's patchset gives us this. Finally: Mirror the interfaces to cpu, print nasty syslog messages about ANY mounts of cpuacct Follow that up by eventually removing cpuacct completely -- In general I think this sets a hard precedent of never allowing an accounting controller to exist with a control one for a given area, e.g. cpu, networking, mm, etc. In the cases where one of these exists already, any attempts to extend (acounting or control) must extend the existing. > > If cpuset and cpu being separate is important enough && the overhead > of doing things separately for cpuset isn't too high, I wouldn't > bother too much with dynamic optimization but that's your call. > Given the choice we would just straight out ripped it out long ago. Breaking the user-space ABI is the problem. > Thanks. > > -- > tejun
next prev parent reply other threads:[~2012-09-06 21:11 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 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 [this message] 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='CAPM31RKVYpkc0oTJKjsdsvqBfif=Bovi3a6TE8qdOOpEYOC0Lw@mail.gmail.com' \ --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 \ --email@example.com \ --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).