From: Peng Wang <rocking@linux.alibaba.com>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] Add busy loop polling for idle SMT
Date: Tue, 16 Nov 2021 19:51:35 +0800 [thread overview]
Message-ID: <cover.1637062971.git.rocking@linux.alibaba.com> (raw)
Now we have cpu_idle_force_poll which uses cpu_relax() waiting for
an arriving IPI, while sometimes busy loop on idle cpu is also
useful to provide consistent pipeline interference for hardware SMT.
When hardware SMT is enabled, the switching between idle and
busy state of one cpu will cause performance fluctuation of
other sibling cpus on the same core.
In pay-for-execution-time scenario, cloud service providers prefer
stable performance data to set stabel price for same workload.
Different execution time of the same workload caused by different
idle or busy state of sibling SMT cpus will make different bills, which
is confused for customers.
Since there is no dynamic CPU time scaling based on SMT pipeline interference,
to coordinate sibling SMT noise no matter whether they are idle or not,
busy loop in idle state can provide approximately consistent pipeline interference.
For example, a workload computing tangent and cotangent will finish in 9071ms when
sibling SMT cpus are idle, and 13299ms when sibling SMT cpus are computiing other workload.
This generate 32% performance fluctuation.
SMT idle polling makes things slower, but we can set bigger cpu quota to make up
a deficiency. This also increase power consumption by 2.2%, which is acceptable.
There may be some other possible solutions, while each has its own problem:
a) disbale hardware SMT, which means half of SMT is unused and more hardware cost.
b) busy loop in a userspace thread, but the cpu usage is confusing.
We propose this patch to discuss the performance fluctuation problem related to SMT
pipeline interference, and any comments are welcome.
Peng Wang (1):
sched/idle: support busy loop polling on idle SMT cpus
arch/Kconfig | 10 ++++++
kernel/sched/core.c | 39 ++++++++++++++++++++++
kernel/sched/idle.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sched/sched.h | 18 +++++++++++
4 files changed, 158 insertions(+)
--
2.9.5
next reply other threads:[~2021-11-16 11:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 11:51 Peng Wang [this message]
2021-11-16 11:51 ` [PATCH] sched/idle: support busy loop polling on idle SMT cpus Peng Wang
2021-11-16 23:08 ` kernel test robot
2021-11-16 23:08 ` kernel test robot
2021-11-18 11:36 ` kernel test robot
2021-11-18 11:36 ` kernel test robot
2021-11-27 15:50 ` kernel test robot
2021-11-27 15:50 ` kernel test robot
2021-11-17 10:58 ` [PATCH] Add busy loop polling for idle SMT Peter Zijlstra
2021-11-19 3:19 ` Peng Wang
2021-11-19 9:25 ` 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=cover.1637062971.git.rocking@linux.alibaba.com \
--to=rocking@linux.alibaba.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.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=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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 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.