From: Peter Zijlstra <peterz@infradead.org>
To: Josh Don <joshdon@google.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Joel Fernandes <joel@joelfernandes.org>,
Vineeth Pillai <vineethrp@gmail.com>, Hao Luo <haoluo@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/core: forced idle accounting
Date: Thu, 14 Oct 2021 16:24:13 +0200 [thread overview]
Message-ID: <YWg9je0wEJsNAd3M@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CABk29NucE__6r3P64Ts3Nbf4sUy5Zkw1sbNNnab9KZ=68ydy=w@mail.gmail.com>
On Tue, Oct 12, 2021 at 12:45:28PM -0700, Josh Don wrote:
> On Tue, Oct 12, 2021 at 5:27 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > > We scale by the number of cpus actually forced idle, since we don't
> > > want to falsely over or under charge forced idle time (defined
> > > strictly as time where we have a runnable task but idle the cpu). The
> > > more important scaling here though is the division over the number of
> > > running entities. This is done so that the aggregate amount of forced
> > > idle over some group of threads makes sense. Ie if we have a cpu with
> > > SMT8, and a group of 7 threads sharing a cookie, we don't want to
> > > accrue 7 units of forced idle time per unit time while the 8th SMT is
> > > forced idle.
> >
> > So why not simply compute the strict per-cpu force-idle time and let
> > userspace sort out the rest?
>
> Do you mean to compute force idle solely as a per-cpu value? I think
> that would be fine in addition to the per-thread field, but a
> desirable property here is proper attribution to the cause of the
> force idle. That lets system management understand which jobs are the
> most antagonistic from a coresched perspective, and is a signal
> (albeit noisy, due to system state and load balancing decisions) for
> scaling their capacity requirements.
Urgh, reading is hard. I hadn't noticed you did per-task accounting (and
the original changelog doesn't clarify this either).
Also, should all this be undef SCHED_DEBUG ? Or be part of SCHEDSTATS ?
next prev parent reply other threads:[~2021-10-14 14:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 0:08 [PATCH] sched/core: forced idle accounting Josh Don
2021-10-08 21:04 ` Josh Don
2021-10-09 15:54 ` Peter Zijlstra
2021-10-12 0:12 ` Josh Don
2021-10-12 12:27 ` Peter Zijlstra
2021-10-12 19:45 ` Josh Don
2021-10-14 14:24 ` Peter Zijlstra [this message]
2021-10-14 23:18 ` Josh Don
2021-10-09 18:11 ` Tao Zhou
2021-10-12 0:14 ` Josh Don
2021-10-11 14:33 ` kernel test robot
2021-10-11 17:33 ` Hao Luo
2021-10-12 0:31 ` Josh Don
2021-10-14 17:57 ` Hao Luo
2021-10-14 23:29 ` Josh Don
2021-10-14 23:58 ` Hao Luo
2021-10-11 18:08 ` kernel test robot
2021-10-11 18:08 ` kernel test robot
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=YWg9je0wEJsNAd3M@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=haoluo@google.com \
--cc=joel@joelfernandes.org \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vineethrp@gmail.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.