On Sat, Jul 26, 2014 at 09:51:52PM -0400, Pranith Kumar wrote: > On Fri, Jul 25, 2014 at 10:30 PM, Frederic Weisbecker > <fweis...@gmail.com> wrote: > > >> I understand that if CONFIG_NO_HZ_FULL_ALL is set then CONFIG_NOCB_CPU_ALL > >> will also be set and there is no need for this cpumask_or(). > >> > >> Is there any reason for the coupling between CONFIG_NO_HZ_FULL_ALL > >> and CONFIG_NOCB_CPU_ALL? > > > > Yeah, for any nohz full CPU, we need the corresponding CPU to be rcu_nocb. > > So if all CPUs are full dynticks, all CPUs must be rcunocb. > > > > That said with this patch, the dependency is perhaps not needed anymore. > > > >> > >> I ask because a user can override CONFIG_NO_HZ_FULL_ALL=y at boot time > >> using the nohz_full= boot time parameter. > > > > No, the content of nohz_full= is ignored with CONFIG_NO_HZ_FULL_ALL=y. > > > > Please correct me if I am wrong but that does not seem to be the case. > If a boot parameter is passed, we are setting up tick_nohz_full_mask > from tick_nohz_full_setup() and marking tick_nohz_full_running as true. > Later on we check this flag and skip the CONFIG_NO_HZ_FULL_ALL > initialization.
You're right, I missed the tick_nohz_full_running check :) So if nohz_full is passed, we ignore CONFIG_NO_HZ_FULL_ALL. That looks like the right behaviour though. Paul what do you think? If we keep that behaviour, Maybe you could blindly do rcu_nocb_mask |= tick_nohz_full and remove the CONFIG_NO_HZ_FULL_ALL dependency on RCU_NOCB_ALL? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
