On Thu, Dec 15, 2016 at 09:20:24AM -0600, Chris Friesen wrote: > 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.) The rcuo/X kthreads can be affined, but the rcuc/X kthreads must run on the corresponding CPU for correctness reasons -- they communicate with RCU core using protocols that are only single-CPU-safe. But if you are running NO_HZ_FULL, these kthreads should never run unless your user threads are doing syscalls. So, are they actually running in your setup? Thanx, Paul -- 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
