From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-team-b10kYP2dOMg@public.gmane.org Subject: Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Date: Sat, 9 Apr 2016 15:39:17 +0200 [thread overview] Message-ID: <20160409133917.GV3448@twins.programming.kicks-ass.net> (raw) In-Reply-To: <20160408201135.GO24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > > Widely diverging from > > > CPU's behavior, IO grouped all internal tasks into an internal leaf > > > node and used to assign a fixed weight to it. > > > > That's just plain broken... That is not how a proportional weight based > > hierarchical controller works. > > That's a strong statement. No its plain fact. If you modify a graph, it is not the same graph. Even if you argue by merit of the function on this graph, and state that only the result of this function is important, and any modification to the graph that leaves this result in tact is good; ie. a modification invariant to the function, this fails. Because for proportional controllers all that matters is the number and weight of edges leaving a node. The modification described above does clearly change the outcome and is not invariant under the proportional weight distribution function. > When the hierarchy is composed of > equivalent objects as in CPU, not distinguishing internal and leaf > nodes would be a more natural way to organize; however, it isn't > necessarily true in all cases. For example, while a writeback IO > would be issued by some task, the task itself might not have done > anything to cause that IO and the IO would essentially be anonymous in > the resource domain. Also, different controllers use different units > of organization - CPU sees threads, IO sees IO contexts which are > usually shared in a process. The difference would lead to differing > scaling behaviors in proportional distribution. > > While the separate buckets and entities model may not be as elegant as > tree of uniform objects, it is far from uncommon and more robust when > dealing with different types of objects. The graph does not care about the type of objects the nodes represent, and proportional weight distribution only cares about the edges. With cpu-cgroup the nodes are not of uniform type either, they can be a group or a task. You get runtime type identification and make it work. There just isn't an excuse for crazy crap like this. Its wrong, no two ways about it.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org> To: Tejun Heo <tj@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, torvalds@linux-foundation.org, akpm@linux-foundation.org, mingo@redhat.com, lizefan@huawei.com, pjt@google.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-api@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Date: Sat, 9 Apr 2016 15:39:17 +0200 [thread overview] Message-ID: <20160409133917.GV3448@twins.programming.kicks-ass.net> (raw) In-Reply-To: <20160408201135.GO24661@htj.duckdns.org> On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > > Widely diverging from > > > CPU's behavior, IO grouped all internal tasks into an internal leaf > > > node and used to assign a fixed weight to it. > > > > That's just plain broken... That is not how a proportional weight based > > hierarchical controller works. > > That's a strong statement. No its plain fact. If you modify a graph, it is not the same graph. Even if you argue by merit of the function on this graph, and state that only the result of this function is important, and any modification to the graph that leaves this result in tact is good; ie. a modification invariant to the function, this fails. Because for proportional controllers all that matters is the number and weight of edges leaving a node. The modification described above does clearly change the outcome and is not invariant under the proportional weight distribution function. > When the hierarchy is composed of > equivalent objects as in CPU, not distinguishing internal and leaf > nodes would be a more natural way to organize; however, it isn't > necessarily true in all cases. For example, while a writeback IO > would be issued by some task, the task itself might not have done > anything to cause that IO and the IO would essentially be anonymous in > the resource domain. Also, different controllers use different units > of organization - CPU sees threads, IO sees IO contexts which are > usually shared in a process. The difference would lead to differing > scaling behaviors in proportional distribution. > > While the separate buckets and entities model may not be as elegant as > tree of uniform objects, it is far from uncommon and more robust when > dealing with different types of objects. The graph does not care about the type of objects the nodes represent, and proportional weight distribution only cares about the edges. With cpu-cgroup the nodes are not of uniform type either, they can be a group or a task. You get runtime type identification and make it work. There just isn't an excuse for crazy crap like this. Its wrong, no two ways about it.
next prev parent reply other threads:[~2016-04-09 13:39 UTC|newest] Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-03-11 15:41 [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 02/10] cgroup: un-inline cgroup_path() and friends Tejun Heo 2016-03-11 15:41 ` [PATCH 04/10] signal: make put_signal_struct() public Tejun Heo 2016-03-11 15:41 ` [PATCH 06/10] cgroup, fork: add @child and @clone_flags to threadgroup_change_begin/end() Tejun Heo 2016-03-11 15:41 ` [PATCH 09/10] cgroup: implement rgroup subtree migration Tejun Heo [not found] ` <1457710888-31182-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-03-11 15:41 ` [PATCH 01/10] cgroup: introduce cgroup_[un]lock() Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 03/10] cgroup: introduce CGRP_MIGRATE_* flags Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 05/10] cgroup, fork: add @new_rgrp_cset[p] and @clone_flags to cgroup fork callbacks Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 07/10] cgroup: introduce resource group Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 08/10] cgroup: implement rgroup control mask handling Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 15:41 ` [PATCH 10/10] cgroup, sched: implement PRIO_RGRP for {set|get}priority() Tejun Heo 2016-03-11 15:41 ` Tejun Heo 2016-03-11 16:05 ` Example program for PRIO_RGRP Tejun Heo 2016-03-11 16:05 ` Tejun Heo 2016-03-12 6:26 ` [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith 2016-03-12 6:26 ` Mike Galbraith [not found] ` <1457764019.10402.72.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-03-12 17:04 ` Mike Galbraith 2016-03-12 17:04 ` Mike Galbraith [not found] ` <1457802262.3628.129.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-03-12 17:13 ` cgroup NAKs ignored? " Ingo Molnar 2016-03-12 17:13 ` Ingo Molnar [not found] ` <20160312171318.GD1108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-03-13 14:42 ` Tejun Heo 2016-03-13 14:42 ` Tejun Heo 2016-03-13 15:00 ` Tejun Heo 2016-03-13 15:00 ` Tejun Heo [not found] ` <20160313150012.GB13405-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-03-13 17:40 ` Mike Galbraith 2016-03-13 17:40 ` Mike Galbraith [not found] ` <1457890835.3859.72.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-04-07 0:00 ` Tejun Heo 2016-04-07 0:00 ` Tejun Heo [not found] ` <20160407000034.GL24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-07 3:26 ` Mike Galbraith 2016-04-07 3:26 ` Mike Galbraith 2016-03-14 2:23 ` Mike Galbraith 2016-03-14 2:23 ` Mike Galbraith 2016-03-14 11:30 ` Peter Zijlstra 2016-03-14 11:30 ` Peter Zijlstra [not found] ` <20160314113013.GM6344-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-06 15:58 ` Tejun Heo 2016-04-06 15:58 ` Tejun Heo 2016-04-06 15:58 ` Tejun Heo [not found] ` <20160406155830.GI24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-07 6:45 ` Peter Zijlstra 2016-04-07 6:45 ` Peter Zijlstra [not found] ` <20160407064549.GH3430-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-07 7:35 ` Johannes Weiner 2016-04-07 7:35 ` Johannes Weiner [not found] ` <20160407073547.GA12560-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2016-04-07 8:05 ` Mike Galbraith 2016-04-07 8:05 ` Mike Galbraith 2016-04-07 8:08 ` Peter Zijlstra 2016-04-07 8:08 ` Peter Zijlstra [not found] ` <20160407080833.GK3430-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-07 9:28 ` Johannes Weiner 2016-04-07 9:28 ` Johannes Weiner [not found] ` <20160407092824.GA13839-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2016-04-07 10:42 ` Peter Zijlstra 2016-04-07 10:42 ` Peter Zijlstra 2016-04-07 19:45 ` Tejun Heo 2016-04-07 19:45 ` Tejun Heo [not found] ` <20160407194555.GI7822-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org> 2016-04-07 20:25 ` Peter Zijlstra 2016-04-07 20:25 ` Peter Zijlstra [not found] ` <20160407202542.GD3448-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-08 20:11 ` Tejun Heo 2016-04-08 20:11 ` Tejun Heo [not found] ` <20160408201135.GO24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-09 6:16 ` Mike Galbraith 2016-04-09 6:16 ` Mike Galbraith 2016-04-09 13:39 ` Peter Zijlstra [this message] 2016-04-09 13:39 ` Peter Zijlstra [not found] ` <20160409133917.GV3448-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-12 22:29 ` Tejun Heo 2016-04-12 22:29 ` Tejun Heo [not found] ` <20160412222915.GT24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-13 7:43 ` Mike Galbraith 2016-04-13 7:43 ` Mike Galbraith 2016-04-13 15:59 ` Tejun Heo [not found] ` <20160413155952.GU24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-13 19:15 ` Mike Galbraith 2016-04-13 19:15 ` Mike Galbraith 2016-04-14 6:07 ` Mike Galbraith [not found] ` <1460614057.5100.150.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-04-14 19:57 ` Tejun Heo 2016-04-14 19:57 ` Tejun Heo [not found] ` <20160414195748.GK7822-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org> 2016-04-15 2:42 ` Mike Galbraith 2016-04-15 2:42 ` Mike Galbraith 2016-04-09 16:02 ` Peter Zijlstra 2016-04-09 16:02 ` Peter Zijlstra 2016-04-07 8:28 ` Peter Zijlstra 2016-04-07 8:28 ` Peter Zijlstra [not found] ` <20160407082810.GN3430-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-07 19:04 ` Johannes Weiner 2016-04-07 19:04 ` Johannes Weiner [not found] ` <20160407190424.GA20407-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2016-04-07 19:31 ` Peter Zijlstra 2016-04-07 19:31 ` Peter Zijlstra [not found] ` <20160407193127.GB3448-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-04-07 20:23 ` Johannes Weiner 2016-04-07 20:23 ` Johannes Weiner [not found] ` <20160407202344.GA22509-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2016-04-08 3:13 ` Mike Galbraith 2016-04-08 3:13 ` Mike Galbraith 2016-03-15 17:21 ` Michal Hocko 2016-03-15 17:21 ` Michal Hocko [not found] ` <20160315172136.GA6114-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> 2016-04-06 21:53 ` Tejun Heo 2016-04-06 21:53 ` Tejun Heo [not found] ` <20160406215307.GJ24661-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> 2016-04-07 6:40 ` Peter Zijlstra 2016-04-07 6:40 ` Peter Zijlstra
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=20160409133917.GV3448@twins.programming.kicks-ass.net \ --to=peterz-wegcikhe2lqwvfeawa7xhq@public.gmane.org \ --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \ --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \ --cc=kernel-team-b10kYP2dOMg@public.gmane.org \ --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \ --cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.