From: Benjamin Segall <bsegall@google.com>
To: Phil Auld <pauld@redhat.com>
Cc: linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <vschneid@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mel Gorman <mgorman@suse.de>,
Frederic Weisbecker <frederic@kernel.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v5 2/2] Sched/fair: Block nohz tick_stop when cfs bandwidth in use
Date: Mon, 10 Jul 2023 16:54:58 -0700 [thread overview]
Message-ID: <xm26lefnfhkd.fsf@google.com> (raw)
In-Reply-To: <20230707195748.2918490-3-pauld@redhat.com> (Phil Auld's message of "Fri, 7 Jul 2023 15:57:48 -0400")
Phil Auld <pauld@redhat.com> writes:
> CFS bandwidth limits and NOHZ full don't play well together. Tasks
> can easily run well past their quotas before a remote tick does
> accounting. This leads to long, multi-period stalls before such
> tasks can run again. Currently, when presented with these conflicting
> requirements the scheduler is favoring nohz_full and letting the tick
> be stopped. However, nohz tick stopping is already best-effort, there
> are a number of conditions that can prevent it, whereas cfs runtime
> bandwidth is expected to be enforced.
>
> Make the scheduler favor bandwidth over stopping the tick by setting
> TICK_DEP_BIT_SCHED when the only running task is a cfs task with
> runtime limit enabled. We use cfs_b->hierarchical_quota to
> determine if the task requires the tick.
>
> Add check in pick_next_task_fair() as well since that is where
> we have a handle on the task that is actually going to be running.
>
> Add check in sched_can_stop_tick() to cover some edge cases such
> as nr_running going from 2->1 and the 1 remains the running task.
>
> Add sched_feat HZ_BW (off by default) to control the tick_stop
> behavior.
>
> Signed-off-by: Phil Auld <pauld@redhat.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Cc: Valentin Schneider <vschneid@redhat.com>
> Cc: Ben Segall <bsegall@google.com>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> ---
> kernel/sched/core.c | 12 ++++++++++
> kernel/sched/fair.c | 49 +++++++++++++++++++++++++++++++++++++++++
> kernel/sched/features.h | 2 ++
> kernel/sched/sched.h | 1 +
> 4 files changed, 64 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1b214e10c25d..4b8534abdf4f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1229,6 +1229,18 @@ bool sched_can_stop_tick(struct rq *rq)
> if (rq->nr_running > 1)
> return false;
>
> + /*
> + * If there is one task and it has CFS runtime bandwidth constraints
> + * and it's on the cpu now we don't want to stop the tick.
> + * This check prevents clearing the bit if a newly enqueued task here is
> + * dequeued by migrating while the constrained task continues to run.
> + * E.g. going from 2->1 without going through pick_next_task().
> + */
> + if (sched_feat(HZ_BW) && rq->nr_running == 1 && task_on_rq_queued(rq->curr)) {
> + if (cfs_task_bw_constrained(rq->curr))
> + return false;
> + }
> +
I think we still need the fair_sched_class check with the bit being on
cfs_rq/tg rather than task.
next prev parent reply other threads:[~2023-07-10 23:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 19:57 [PATCH v5 0/2] Fix nohz_full vs cfs bandwidth Phil Auld
2023-07-07 19:57 ` [PATCH v5 1/2] sched, cgroup: Restore meaning to hierarchical_quota Phil Auld
2023-07-10 20:17 ` Tejun Heo
2023-07-10 21:04 ` Phil Auld
2023-07-11 0:00 ` Benjamin Segall
2023-07-11 13:13 ` Phil Auld
2023-07-07 19:57 ` [PATCH v5 2/2] Sched/fair: Block nohz tick_stop when cfs bandwidth in use Phil Auld
2023-07-10 23:54 ` Benjamin Segall [this message]
2023-07-11 13:10 ` Phil Auld
2023-07-11 14:12 ` Phil Auld
2023-07-11 22:07 ` Benjamin Segall
2023-07-11 22:22 ` Phil Auld
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=xm26lefnfhkd.fsf@google.com \
--to=bsegall@google.com \
--cc=bristot@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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.