From: Peter Zijlstra <peterz@infradead.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, pjt@google.com,
dietmar.eggemann@arm.com, mingo@redhat.com,
morten.rasmussen@arm.com, tglx@linutronix.de,
mgorman@techsingularity.net, vincent.guittot@linaro.org
Subject: Re: [PATCH RFC v3 0/14] sched,fair: flatten CPU controller runqueues
Date: Tue, 30 Jul 2019 18:29:33 +0200 [thread overview]
Message-ID: <20190730162933.GW31398@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190722173348.9241-1-riel@surriel.com>
On Mon, Jul 22, 2019 at 01:33:34PM -0400, Rik van Riel wrote:
> Plan for the CONFIG_CFS_BANDWIDTH reimplementation:
> - When a cgroup gets throttled, mark the cgroup and its children
> as throttled.
> - When pick_next_entity finds a task that is on a throttled cgroup,
> stash it on the cgroup runqueue (which is not used for runnable
> tasks any more). Leave the vruntime unchanged, and adjust that
> runqueue's vruntime to be that of the left-most task.
and ignore such tasks for the load-balancer; I suppose
> - When a cgroup gets unthrottled, and has tasks on it, place it on
> a vruntime ordered heap separate from the main runqueue.
and expose said heap to the load-balancer..
Now, I suppose you do this because merging heaps is easier than merging
RB trees? (not in complexity iirc, but probably in code)
> - Have pick_next_task_fair grab one task off that heap every time it
> is called, and the min vruntime of that heap is lower than the
> vruntime of the CPU's cfs_rq (or the CPU has no other runnable tasks).
That's like a smeared out merge :-) But since the other tasks kept on
running, this CPUs vruntime will be (much) advanced vs those throttled
tasks and we'll most likely end up picking them all before we pick a
'normal' task.
> - Place that selected task on the CPU's cfs_rq, renormalizing its
> vruntime with the GENTLE_FAIR_SLEEPERS logic. That should help
> interleave the already runnable tasks with the recently unthrottled
> group, and prevent thundering herd issues.
> - If the group gets throttled again before all of its task had a chance
> to run, vruntime sorting ensures all the tasks in the throttled cgroup
> get a chance to run over time.
next prev parent reply other threads:[~2019-07-30 16:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 17:33 [PATCH RFC v3 0/14] sched,fair: flatten CPU controller runqueues Rik van Riel
2019-07-22 17:33 ` [PATCH 01/14] sched: introduce task_se_h_load helper Rik van Riel
2019-08-12 17:40 ` Dietmar Eggemann
2019-07-22 17:33 ` [PATCH 02/14] sched: change /proc/sched_debug fields Rik van Riel
2019-07-22 17:33 ` [PATCH 03/14] sched,fair: redefine runnable_load_avg as the sum of task_h_load Rik van Riel
2019-07-29 20:05 ` Peter Zijlstra
2019-07-29 21:13 ` Rik van Riel
2019-07-29 20:11 ` Peter Zijlstra
2019-07-29 20:26 ` Peter Zijlstra
2019-07-22 17:33 ` [PATCH 04/14] sched,fair: move runnable_load_avg to cfs_rq Rik van Riel
2019-07-30 8:55 ` Peter Zijlstra
2019-07-22 17:33 ` [PATCH 06/14] sched,cfs: use explicit cfs_rq of parent se helper Rik van Riel
2019-07-22 17:33 ` [PATCH 07/14] sched,cfs: fix zero length timeslice calculation Rik van Riel
2019-07-22 17:33 ` [PATCH 08/14] sched,fair: simplify timeslice length code Rik van Riel
2019-07-22 17:33 ` [PATCH 09/14] sched,fair: refactor enqueue/dequeue_entity Rik van Riel
2019-07-30 9:36 ` Peter Zijlstra
2019-07-30 12:58 ` Rik van Riel
2019-07-31 9:35 ` Peter Zijlstra
2019-07-31 15:03 ` Rik van Riel
2019-07-31 15:30 ` Peter Zijlstra
2019-07-22 17:33 ` [PATCH 10/14] sched,fair: add helper functions for flattened runqueue Rik van Riel
2019-07-22 17:33 ` [PATCH 11/14] sched,fair: flatten hierarchical runqueues Rik van Riel
2019-07-22 17:33 ` [PATCH 12/14] sched,fair: track cfs_rq->max_h_load for more legitimate h_weight Rik van Riel
2019-07-22 17:33 ` [PATCH 13/14] sched,fair: flatten update_curr functionality Rik van Riel
2019-07-22 17:33 ` [PATCH 14/14] sched,fair: propagate sum_exec_runtime up the hierarchy Rik van Riel
2019-07-30 16:29 ` Peter Zijlstra [this message]
2019-07-30 18:27 ` [PATCH RFC v3 0/14] sched,fair: flatten CPU controller runqueues Rik van Riel
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=20190730162933.GW31398@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=pjt@google.com \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox