From: Luiz Capitulino <lcapitulino@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: riel@redhat.com, rafael.j.wysocki@intel.com, mingo@kernel.org
Subject: [RFC 0/3] sched/idle: run-time support for setting idle polling
Date: Tue, 22 Sep 2015 16:34:19 -0400 [thread overview]
Message-ID: <1442954062-28578-1-git-send-email-lcapitulino@redhat.com> (raw)
Hi,
Some archs allow the system administrator to set the
idle thread behavior to spin instead of entering
sleep states. The x86 arch, for example, has a idle=
command-line parameter for this purpose.
However, the command-line parameter has two problems:
1. You have to reboot if you change your mind
2. This setting affects all system cores
The second point is relevant for systems where cores
are partitioned into bookkeeping and low-latency cores.
Usually, it's OK for bookkeeping cores to enter deeper
sleep states. It's only the low-latency cores that should
poll when entering idle.
This series adds the following file:
/sys/devices/system/cpu/cpu_idle
This file outputs and stores a cpumask of the cores
which will have idle polling behavior.
This implementation seems to work fine on x86, however
it's RFC because of the following points (for which
feedback is greatly appreciated):
o I believe this implementation should work for all archs,
but I can't confirm it as my machines and experience is
limited to x86
o Some x86 cpufreq drivers explicitly check if idle=poll
was passed. Does anyone know if this is an optmization
or is there actually a conflict between idle=poll and
driver operation?
o This series maintains cpu_idle_poll_ctrl() semantics
which led to a more complex implementation. That is, today
cpu_idle_poll_ctrl() increments or decrements a counter.
A lot of arch code seems to count on this semantic, where
cpu_idle_poll_ctrl(enable or false) calls have to match to
enable or disable idle polling
Luiz Capitulino (3):
sched/idle: cpu_idle_poll(): drop unused return code
sched/idle: make cpu_idle_force_poll per-cpu
sched/idle: run-time support for setting idle polling
drivers/base/cpu.c | 44 ++++++++++++++++++++++++
include/linux/cpu.h | 2 ++
kernel/sched/idle.c | 96 +++++++++++++++++++++++++++++++++++++++++++++--------
3 files changed, 129 insertions(+), 13 deletions(-)
--
2.1.0
next reply other threads:[~2015-09-22 20:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 20:34 Luiz Capitulino [this message]
2015-09-22 20:34 ` [RFC 1/3] sched/idle: cpu_idle_poll(): drop unused return code Luiz Capitulino
2015-09-22 20:34 ` [RFC 2/3] sched/idle: make cpu_idle_force_poll per-cpu Luiz Capitulino
2015-09-22 20:34 ` [RFC 3/3] sched/idle: run-time support for setting idle polling Luiz Capitulino
2015-09-23 1:17 ` [RFC 0/3] " Rafael J. Wysocki
2015-09-23 13:21 ` Luiz Capitulino
2015-09-30 15:48 ` Peter Zijlstra
2015-09-30 17:16 ` Luiz Capitulino
2015-09-30 17:27 ` Peter Zijlstra
2015-09-30 18:01 ` Luiz Capitulino
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=1442954062-28578-1-git-send-email-lcapitulino@redhat.com \
--to=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=riel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®