This is a rebase and retest of two fixes I'd sent earlier[1].
The rebase is required due to conflicts in my patch #1 and where Frederic updated
the unwind code in housekeeping_setup in his series[2] and that series is now
in sched/core of tip[3].
So this update is against a baseline of ed3b362d54f0 found in sched/core as
"sched/isolation: Split housekeeping cpumask per isolation features" in tip.
Changes amount to "return 0" ---> "goto out_free" and adding a nod to PaulM's
observation that nohz_full w/o a cpuset is coming someday into the commit log.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/
[3] git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
----- Original v1 text follows -----
A couple months back I sent a fix to reconcile rcu_nocbs= input
restrictions with nohz_full= input restrictions; with the latter being
more restrictive than the former.
However, in relaxing the nohz_full restrictions, I made it possible to
boot with a nohz_full= parameter that contains nothing but nonexistent
and not-possible cores - which will trigger a WARN.
This fixes the original reconcile commit by explicitly coding our
allowed values just like RCU does, and changes the WARN_ON to a
WARN_ON_ONCE, since it needlessly rendered the machine unusable.
---
Cc: Frederic Weisbecker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Paul Gortmaker (2):
sched/isolation: really align nohz_full with rcu_nocbs
tick/nohz: WARN_ON --> WARN_ON_ONCE to prevent console saturation
kernel/sched/isolation.c | 11 +++++++++++
kernel/time/tick-sched.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.17.1