Re: [RFC PATCH 1/1] rcu: Allow user to ovveride RCU_NOCB_CPU_ALL at boot time

From: Pranith Kumar
Date: Wed Jul 16 2014 - 20:47:50 EST


On 07/16/2014 08:26 PM, Paul E. McKenney wrote:
> On Wed, Jul 16, 2014 at 06:38:08PM -0400, Pranith Kumar wrote:
>> A kernel built with RCU_NOCB_CPU_ALL build time option will offload callbacks
>> from all CPUs. The user cannot override this behavior without recompiling the
>> kernel with the RCU_NOCB_CPU_ALL option turned off.
>>
>> This commit allows the user to override the build-time option by using the
>> rcu_nocbs= boot time option without needing to recompile the kernel.
>>
>> Please note that this is how NO_HZ_FULL_ALL build time option works and this
>> commit makes it work similar to that.
>>
>> Signed-off-by: Pranith Kumar <bobby.prani@xxxxxxxxx>

Hi Paul,

> I cannot accept this patch. For one thing, tick_nohz_init_all() looks
> a bit on the unconditional side when CONFIG_NO_HZ_FULL_ALL=y. For
> another thing, we really do not want to be handing the user a tool that
> allows CPUs that are nohz_full to not be no-CBs CPUs. For another thing,

I thought the latest patch does not allow that by ORing the nohz_full and
rcu_nocbs mask. Doesn't it? All nohz_full CPUs will be nocb CPUS. We can mention
this explicitly in the kernel-parameters.txt file.

> if we add this and it turns out to be a bad idea, it will be difficult
> to take it back -- someone somewhere will no doubt have scripted the
> boot parameter.

This option already exists in the kernel when RCU_NOCB_CPU_ALL is not set. The
user can pass in rcu_nocbs= at boot time. I am not sure we are adding anything
new with this patch.

Most of the distro kernels set RCU_NOCB_CPU_ALL and rightly so, as it is the
suggested and most appropriate option. This patch will make it easier for users
who want to specify nocb CPUs for their needs, without having to recompile the
kernel.

>
> Thanx, Paul
>
>

--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/