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>
Subject: Re: [PATCH v2] sched/nohz: Add HRTICK_BW for using cfs bandwidth with nohz_full
Date: Mon, 12 Jun 2023 13:43:35 -0700 [thread overview]
Message-ID: <xm26fs6w9zt4.fsf@google.com> (raw)
In-Reply-To: <20230608125228.56097-1-pauld@redhat.com> (Phil Auld's message of "Thu, 8 Jun 2023 08:52:28 -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. Use the hrtick mechanism to set a sched
> tick to fire at remaining_runtime in the future if we are on
> a nohz full cpu, if the task has quota and if we are likely to
> disable the tick (nr_running == 1). This allows for bandwidth
> accounting before tasks go too far over quota.
>
> A number of container workloads use a dynamic number of real
> nohz tasks but also have other work that is limited which ends
> up running on the "spare" nohz cpus. This is an artifact of
> having to specify nohz_full cpus at boot. Adding this hrtick
> resolves the issue of long stalls on these tasks. Currently
> the scheduler, when faced with these conflicting requirements
> choosed to favor nohz_full even though that is already best
> effort. Here we make it favor respecting the bandwidth
> limitations which are not supposed to be best effort.
>
> Add the sched_feat HRTICK_BW off by default to allow users to
> enable this only when needed.
>
> Signed-off-by: Phil Auld <pauld@redhat.com>
> Suggested-by: Juri Lelli <jlelli@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>
> ---
>
> v2: Clean up building issues with various related CONFIG changes. Add a
> check to start the hrtick in __account_cfs_rq_runtime() for when the
> task gets more runtime.
This starts the hrtick before/without going through schedule, but the
fact that it's still the standard hrtick()->task_tick(queued=1) means it
will still set need_resched even if it succeeds at getting runtime.
next prev parent reply other threads:[~2023-06-12 20:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 12:52 [PATCH v2] sched/nohz: Add HRTICK_BW for using cfs bandwidth with nohz_full Phil Auld
2023-06-12 20:43 ` Benjamin Segall [this message]
2023-06-12 21:38 ` 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=xm26fs6w9zt4.fsf@google.com \
--to=bsegall@google.com \
--cc=bristot@redhat.com \
--cc=dietmar.eggemann@arm.com \
--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=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.