| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/2 [
Author: Paul Gortmaker
Email: paul.gortmaker@windriver.com
Subject: sched/isolation: really align nohz_full with rcu_nocbs
Date: Fri, 4 Mar 2022 09:42:19 -0500
At the moment it is currently possible to sneak a core into nohz_full
that lies between nr_possible and NR_CPUS - but you won't "see" it
because cpumask_pr_args() implicitly hides anything above nr_cpu_ids.
This becomes a problem when the nohz_full CPU set doesn't contain at
least one other valid nohz CPU - in which case we end up with the
tick_nohz_full_running set and no tick core specified, which trips an
endless sequence of WARN() and renders the machine unusable.
I inadvertently opened the door for this when fixing an overly
restrictive nohz_full conditional in the below Fixes: commit - and then
courtesy of my optimistic ACPI reporting nr_possible of 64 (the default
Kconfig for NR_CPUS) and the not-so helpful implict filtering done by
cpumask_pr_args, I unfortunately did not spot it during my testing.
So here, I don't rely on what was printed anymore, but code exactly what
our restrictions should be in order to be aligned with rcu_nocbs - which
was the original goal. Since the checks lie in "__init" code it is largely
free for us to do this anyway.
Building with NOHZ_FULL and NR_CPUS=128 on an otherwise defconfig, and
booting with "rcu_nocbs=8-127 nohz_full=96-127" on the same 16 core T5500
Dell machine now results in the following (only relevant lines shown):
smpboot: Allowing 64 CPUs, 48 hotplug CPUs
setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:64 nr_node_ids:2
housekeeping: kernel parameter 'nohz_full=' or 'isolcpus=' contains nonexistent CPUs.
housekeeping: kernel parameter 'nohz_full=' or 'isolcpus=' has no valid CPUs.
rcu: RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=64.
rcu: Note: kernel parameter 'rcu_nocbs=', 'nohz_full', or 'isolcpus=' contains nonexistent CPUs.
rcu: Offload RCU callbacks from CPUs: 8-63.
One can see both new housekeeping checks are triggered in the above.
The same invalid boot arg combination would have previously resulted in
an infinitely scrolling mix of WARN from all cores per tick on this box.
Link: https://lore.kernel.org/lkml/20211206145950.10927-2-paul.gortmaker@windriver.com
Fixes: 915a2bc3c6b7 ("sched/isolation: Reconcile rcu_nocbs= and nohz_full=")
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/2 [
Author: Paul Gortmaker
Email: paul.gortmaker@windriver.com
Subject: tick/nohz: WARN_ON --> WARN_ON_ONCE to prevent console saturation
Date: Fri, 4 Mar 2022 09:42:20 -0500
While running some testing on code that happened to allow the variable
tick_nohz_full_running to get set but with no "possible" NOHZ cores to
back up that setting, I tripped this WARN:
if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE))
WARN_ON(tick_nohz_full_running);
The console was overwhemled with an endless stream of one WARN per tick
per core and there was no way to even see what was going on w/o using a
serial console to capture it and then trace it back to this guy.
Changing it to ONCE reveals that we get the message we need in a
civilized fashion, and the system can limp along until rebooted.
Link: https://lore.kernel.org/lkml/20211206145950.10927-3-paul.gortmaker@windriver.com
Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full")
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/3 [
Author: Paul Gortmaker
Email: paul.gortmaker@windriver.com
Subject: clear_warn_once: expand debugfs to include read support
Date: Wed, 16 Dec 2020 12:22:56 -0500
The existing clear_warn_once variable is write-only; used as per the
documentation to reset the warn_once to as-booted state with:
echo 1 > /sys/kernel/debug/clear_warn_once
The objective is to expand on that functionality, which requires the
debugfs variable to be read/write and not just write-only.
Here, we deal with the debugfs boilerplate associated with converting
it from write-only to read-write, in order to factor that out for easier
review, and for what may be a possible future useful bisect point.
Existing functionality is unchanged - the only difference is that we
have tied in a variable that lets you now read the variable and see
the last value written.
Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/3 [
Author: Paul Gortmaker
Email: paul.gortmaker@windriver.com
Subject: clear_warn_once: bind a timer to written reset value
Date: Wed, 16 Dec 2020 12:22:57 -0500
Existing documentation has a write of "1" to clear/reset all the
WARN_ONCE and similar to the as-booted state, so they can possibly
be re-triggered again during debugging/testing.
But having them auto-reset once a day, or once a week, might shed
valuable information to a sysadmin on what the system is doing while
trying to debug an issue.
Here we extend the existing debugfs variable to bind a timer to the
written value N, so that it will reset every N minutes, for N>1.
Writing a zero will clear any previously set timer value.
The pre-existing behaviour of writing N=1 will do a one-shot clear.
Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
3/3 [
Author: Paul Gortmaker
Email: paul.gortmaker@windriver.com
Subject: clear_warn_once: add a clear_warn_once= boot parameter
Date: Wed, 16 Dec 2020 12:22:58 -0500
In the event debugfs is not mounted, or if built with the .config
setting DEBUG_FS_ALLOW_NONE chosen, this gives the sysadmin access
to reset the WARN_ONCE() state on a periodic basis.
Link: https://lore.kernel.org/r/20201126063029.2030-1-paul.gortmaker@windriver.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
Bruce Ashfield