All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.