From: Daniel Bristot de Oliveira <daniel@bristot.me>
To: Chris Friesen <chris.friesen@windriver.com>,
linux-rt-users@vger.kernel.org
Subject: Re: question about rcuc/X tasks
Date: Thu, 15 Dec 2016 14:47:37 +0100 [thread overview]
Message-ID: <518a5f66-76d0-e356-b08b-bde2a7a17bb2@bristot.me> (raw)
In-Reply-To: <584F27B8.2090406@windriver.com>
Hi Chris,
On 12/12/2016 11:42 PM, Chris Friesen wrote:
> Based on the fact that Documentation/kernel-per-CPU-kthreads.txt
> describes CONFIG_RCU_NOCB_CPU_ALL=y as a solution by preventing the
> rcuc/%u kthreads from having any work to do, I had expected that the
> "rcu_nocbs=1-15" kernel parameter would have a similar effect.
As far as I recall, using CONFIG_RCU_NOCB_CPU_ALL=y will prevent the RCU
callbacks from running on rcuc/X threads (which are pinned to the CPU
X), but the rcuc/X thread is still in charge of awaking the ruco*
threads of the CPU X.
> Does anyone have any idea what's going on here, and how I can prevent
> the rcuc/<cpu> tasks from waking up?
You can try to use rcu_nocb_poll kernel parameter to unload the rcuc/X
thread of the task of awaking its respective ruco*s threads.
>From [1]:
rcu_nocb_poll [KNL]
Rather than requiring that offloaded CPUs
(specified by rcu_nocbs= above) explicitly
awaken the corresponding "rcuoN" kthreads,
make these kthreads poll for callbacks.
This improves the real-time response for the
offloaded CPUs by relieving them of the need to
wake up the corresponding kthread, but degrades
energy efficiency by requiring that the kthreads
periodically wake up to do the polling.
[1] https://www.kernel.org/doc/Documentation/kernel-parameters.txt
-- Daniel
next prev parent reply other threads:[~2016-12-15 13:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 22:42 question about rcuc/X tasks Chris Friesen
2016-12-15 13:47 ` Daniel Bristot de Oliveira [this message]
2016-12-15 14:07 ` Steven Rostedt
2016-12-15 15:20 ` Chris Friesen
2016-12-15 19:04 ` Paul E. McKenney
2016-12-15 22:23 ` Chris Friesen
2016-12-15 23:34 ` Paul E. McKenney
2016-12-16 2:43 ` Chris Friesen
2016-12-15 19:01 ` Paul E. McKenney
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=518a5f66-76d0-e356-b08b-bde2a7a17bb2@bristot.me \
--to=daniel@bristot.me \
--cc=chris.friesen@windriver.com \
--cc=linux-rt-users@vger.kernel.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.