On 12/15/2016 08:07 AM, Steven Rostedt wrote:
On Thu, 15 Dec 2016 14:47:37 +0100
Daniel Bristot de Oliveira <daniel@xxxxxxxxxx> wrote:
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.
Paul, would rcu_nocbs=1-15 work? Or should ALL be used ? I'm assuming
this is on a 16 CPUs box, in which case I don't see much of a difference
for not just using ALL as it is almost there anyway ;-)
-- Steve
Yes, this was a 16 CPU box.
The blocker for CONFIG_RCU_NOCB_CPU_ALL is that the set of
management/housekeeping CPUs is configurable by the end-user, so while it
defaults to only CPU0 as management it's not guaranteed that it will always be
that way.
On a related note, I found an old email from Paul suggesting that the various
rcuc/X threads could be affined to the management CPUs to free up the "realtime"
cores, but when I try that it doesn't let me change affinity. Was that
disallowed for technical reasons? (It's also possible it's something local, in
which case I need to go digging.)
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html