* [PATCH v15 1/7] timers: Rename tmigr 'online' bit to 'available'
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-19 15:49 ` Thomas Gleixner
2025-11-13 8:33 ` [PATCH v15 2/7] timers: Add the available mask in timer migration Gabriele Monaco
` (6 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco
The timer migration hierarchy excludes offline CPUs via the
tmigr_is_not_available function, which is essentially checking the
online bit for the CPU.
Rename the online bit to available and all references in function names
and tracepoint to generalise the concept of available CPUs.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
include/trace/events/timer_migration.h | 4 ++--
kernel/time/timer_migration.c | 24 ++++++++++++------------
kernel/time/timer_migration.h | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/include/trace/events/timer_migration.h b/include/trace/events/timer_migration.h
index 47db5eaf2f9a..61171b13c687 100644
--- a/include/trace/events/timer_migration.h
+++ b/include/trace/events/timer_migration.h
@@ -173,14 +173,14 @@ DEFINE_EVENT(tmigr_cpugroup, tmigr_cpu_active,
TP_ARGS(tmc)
);
-DEFINE_EVENT(tmigr_cpugroup, tmigr_cpu_online,
+DEFINE_EVENT(tmigr_cpugroup, tmigr_cpu_available,
TP_PROTO(struct tmigr_cpu *tmc),
TP_ARGS(tmc)
);
-DEFINE_EVENT(tmigr_cpugroup, tmigr_cpu_offline,
+DEFINE_EVENT(tmigr_cpugroup, tmigr_cpu_unavailable,
TP_PROTO(struct tmigr_cpu *tmc),
diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
index 19ddfa96b9df..d50514062a06 100644
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -429,7 +429,7 @@ static DEFINE_PER_CPU(struct tmigr_cpu, tmigr_cpu);
static inline bool tmigr_is_not_available(struct tmigr_cpu *tmc)
{
- return !(tmc->tmgroup && tmc->online);
+ return !(tmc->tmgroup && tmc->available);
}
/*
@@ -926,7 +926,7 @@ static void tmigr_handle_remote_cpu(unsigned int cpu, u64 now,
* updated the event takes care when hierarchy is completely
* idle. Otherwise the migrator does it as the event is enqueued.
*/
- if (!tmc->online || tmc->remote || tmc->cpuevt.ignore ||
+ if (!tmc->available || tmc->remote || tmc->cpuevt.ignore ||
now < tmc->cpuevt.nextevt.expires) {
raw_spin_unlock_irq(&tmc->lock);
return;
@@ -973,7 +973,7 @@ static void tmigr_handle_remote_cpu(unsigned int cpu, u64 now,
* (See also section "Required event and timerqueue update after a
* remote expiry" in the documentation at the top)
*/
- if (!tmc->online || !tmc->idle) {
+ if (!tmc->available || !tmc->idle) {
timer_unlock_remote_bases(cpu);
goto unlock;
}
@@ -1422,19 +1422,19 @@ static long tmigr_trigger_active(void *unused)
{
struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
- WARN_ON_ONCE(!tmc->online || tmc->idle);
+ WARN_ON_ONCE(!tmc->available || tmc->idle);
return 0;
}
-static int tmigr_cpu_offline(unsigned int cpu)
+static int tmigr_clear_cpu_available(unsigned int cpu)
{
struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
int migrator;
u64 firstexp;
raw_spin_lock_irq(&tmc->lock);
- tmc->online = false;
+ tmc->available = false;
WRITE_ONCE(tmc->wakeup, KTIME_MAX);
/*
@@ -1442,7 +1442,7 @@ static int tmigr_cpu_offline(unsigned int cpu)
* offline; Therefore nextevt value is set to KTIME_MAX
*/
firstexp = __tmigr_cpu_deactivate(tmc, KTIME_MAX);
- trace_tmigr_cpu_offline(tmc);
+ trace_tmigr_cpu_unavailable(tmc);
raw_spin_unlock_irq(&tmc->lock);
if (firstexp != KTIME_MAX) {
@@ -1453,7 +1453,7 @@ static int tmigr_cpu_offline(unsigned int cpu)
return 0;
}
-static int tmigr_cpu_online(unsigned int cpu)
+static int tmigr_set_cpu_available(unsigned int cpu)
{
struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
@@ -1462,11 +1462,11 @@ static int tmigr_cpu_online(unsigned int cpu)
return -EINVAL;
raw_spin_lock_irq(&tmc->lock);
- trace_tmigr_cpu_online(tmc);
+ trace_tmigr_cpu_available(tmc);
tmc->idle = timer_base_is_idle();
if (!tmc->idle)
__tmigr_cpu_activate(tmc);
- tmc->online = true;
+ tmc->available = true;
raw_spin_unlock_irq(&tmc->lock);
return 0;
}
@@ -1758,7 +1758,7 @@ static int tmigr_add_cpu(unsigned int cpu)
* The (likely) current CPU is expected to be online in the hierarchy,
* otherwise the old root may not be active as expected.
*/
- WARN_ON_ONCE(!per_cpu_ptr(&tmigr_cpu, raw_smp_processor_id())->online);
+ WARN_ON_ONCE(!per_cpu_ptr(&tmigr_cpu, raw_smp_processor_id())->available);
ret = tmigr_setup_groups(-1, old_root->numa_node, old_root, true);
}
@@ -1854,7 +1854,7 @@ static int __init tmigr_init(void)
goto err;
ret = cpuhp_setup_state(CPUHP_AP_TMIGR_ONLINE, "tmigr:online",
- tmigr_cpu_online, tmigr_cpu_offline);
+ tmigr_set_cpu_available, tmigr_clear_cpu_available);
if (ret)
goto err;
diff --git a/kernel/time/timer_migration.h b/kernel/time/timer_migration.h
index ae19f70f8170..70879cde6fdd 100644
--- a/kernel/time/timer_migration.h
+++ b/kernel/time/timer_migration.h
@@ -97,7 +97,7 @@ struct tmigr_group {
*/
struct tmigr_cpu {
raw_spinlock_t lock;
- bool online;
+ bool available;
bool idle;
bool remote;
struct tmigr_group *tmgroup;
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v15 1/7] timers: Rename tmigr 'online' bit to 'available'
2025-11-13 8:33 ` [PATCH v15 1/7] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
@ 2025-11-19 15:49 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 15:49 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Waiman Long
Cc: Gabriele Monaco
On Thu, Nov 13 2025 at 09:33, Gabriele Monaco wrote:
> The timer migration hierarchy excludes offline CPUs via the
> tmigr_is_not_available function, which is essentially checking the
> online bit for the CPU.
>
> Rename the online bit to available and all references in function names
> and tracepoint to generalise the concept of available CPUs.
>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v15 2/7] timers: Add the available mask in timer migration
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 1/7] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-19 15:56 ` Thomas Gleixner
2025-11-13 8:33 ` [PATCH v15 3/7] timers: Use scoped_guard when setting/clearing the tmigr available flag Gabriele Monaco
` (5 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco
Keep track of the CPUs available for timer migration in a cpumask. This
prepares the ground to generalise the concept of unavailable CPUs.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
kernel/time/timer_migration.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
index d50514062a06..b8f07e4f59a6 100644
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -424,6 +424,12 @@ static struct tmigr_group *tmigr_root;
static DEFINE_PER_CPU(struct tmigr_cpu, tmigr_cpu);
+/*
+ * CPUs available for timer migration.
+ * Protected by cpuset_mutex (with cpus_read_lock held) or cpus_write_lock.
+ */
+static cpumask_var_t tmigr_available_cpumask;
+
#define TMIGR_NONE 0xFF
#define BIT_CNT 8
@@ -1433,6 +1439,7 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
int migrator;
u64 firstexp;
+ cpumask_clear_cpu(cpu, tmigr_available_cpumask);
raw_spin_lock_irq(&tmc->lock);
tmc->available = false;
WRITE_ONCE(tmc->wakeup, KTIME_MAX);
@@ -1446,7 +1453,7 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
raw_spin_unlock_irq(&tmc->lock);
if (firstexp != KTIME_MAX) {
- migrator = cpumask_any_but(cpu_online_mask, cpu);
+ migrator = cpumask_any(tmigr_available_cpumask);
work_on_cpu(migrator, tmigr_trigger_active, NULL);
}
@@ -1461,6 +1468,7 @@ static int tmigr_set_cpu_available(unsigned int cpu)
if (WARN_ON_ONCE(!tmc->tmgroup))
return -EINVAL;
+ cpumask_set_cpu(cpu, tmigr_available_cpumask);
raw_spin_lock_irq(&tmc->lock);
trace_tmigr_cpu_available(tmc);
tmc->idle = timer_base_is_idle();
@@ -1805,6 +1813,11 @@ static int __init tmigr_init(void)
if (ncpus == 1)
return 0;
+ if (!zalloc_cpumask_var(&tmigr_available_cpumask, GFP_KERNEL)) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
/*
* Calculate the required hierarchy levels. Unfortunately there is no
* reliable information available, unless all possible CPUs have been
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v15 2/7] timers: Add the available mask in timer migration
2025-11-13 8:33 ` [PATCH v15 2/7] timers: Add the available mask in timer migration Gabriele Monaco
@ 2025-11-19 15:56 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 15:56 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Waiman Long
Cc: Gabriele Monaco
On Thu, Nov 13 2025 at 09:33, Gabriele Monaco wrote:
Can we please consistently have 'timers/migration:' as prefix like the
other existing commits for this series?
That allows to write this subject line in a coherent way:
timers/migration: Provide and use cpumask for available CPUs
or something like that.
Why did I waste time for documenting all of this?
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject
"‘git log path/to/file’ should give you a reasonable hint in most cases."
Is it really that hard?
> Keep track of the CPUs available for timer migration in a cpumask. This
> prepares the ground to generalise the concept of unavailable CPUs.
>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Aside of the nit above:
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v15 3/7] timers: Use scoped_guard when setting/clearing the tmigr available flag
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 1/7] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 2/7] timers: Add the available mask in timer migration Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-19 15:57 ` Thomas Gleixner
2025-11-13 8:33 ` [PATCH v15 4/7] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_isolation_cpumasks() Gabriele Monaco
` (4 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco
Cleanup tmigr_clear_cpu_available() and tmigr_set_cpu_available() to
prepare for easier checks on the available flag.
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
kernel/time/timer_migration.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
index b8f07e4f59a6..d3eb9714e692 100644
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -1440,17 +1440,17 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
u64 firstexp;
cpumask_clear_cpu(cpu, tmigr_available_cpumask);
- raw_spin_lock_irq(&tmc->lock);
- tmc->available = false;
- WRITE_ONCE(tmc->wakeup, KTIME_MAX);
+ scoped_guard(raw_spinlock_irq, &tmc->lock) {
+ tmc->available = false;
+ WRITE_ONCE(tmc->wakeup, KTIME_MAX);
- /*
- * CPU has to handle the local events on his own, when on the way to
- * offline; Therefore nextevt value is set to KTIME_MAX
- */
- firstexp = __tmigr_cpu_deactivate(tmc, KTIME_MAX);
- trace_tmigr_cpu_unavailable(tmc);
- raw_spin_unlock_irq(&tmc->lock);
+ /*
+ * CPU has to handle the local events on his own, when on the way to
+ * offline; Therefore nextevt value is set to KTIME_MAX
+ */
+ firstexp = __tmigr_cpu_deactivate(tmc, KTIME_MAX);
+ trace_tmigr_cpu_unavailable(tmc);
+ }
if (firstexp != KTIME_MAX) {
migrator = cpumask_any(tmigr_available_cpumask);
@@ -1469,13 +1469,13 @@ static int tmigr_set_cpu_available(unsigned int cpu)
return -EINVAL;
cpumask_set_cpu(cpu, tmigr_available_cpumask);
- raw_spin_lock_irq(&tmc->lock);
- trace_tmigr_cpu_available(tmc);
- tmc->idle = timer_base_is_idle();
- if (!tmc->idle)
- __tmigr_cpu_activate(tmc);
- tmc->available = true;
- raw_spin_unlock_irq(&tmc->lock);
+ scoped_guard(raw_spinlock_irq, &tmc->lock) {
+ trace_tmigr_cpu_available(tmc);
+ tmc->idle = timer_base_is_idle();
+ if (!tmc->idle)
+ __tmigr_cpu_activate(tmc);
+ tmc->available = true;
+ }
return 0;
}
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v15 4/7] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_isolation_cpumasks()
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
` (2 preceding siblings ...)
2025-11-13 8:33 ` [PATCH v15 3/7] timers: Use scoped_guard when setting/clearing the tmigr available flag Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 5/7] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
` (3 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco, Chen Ridong
update_unbound_workqueue_cpumask() updates unbound workqueues settings
when there's a change in isolated CPUs, but it can be used for other
subsystems requiring updated when isolated CPUs change.
Generalise the name to update_isolation_cpumasks() to prepare for other
functions unrelated to workqueues to be called in that spot.
[longman: Change the function name to update_isolation_cpumasks()]
Acked-by: Frederic Weisbecker <frederic@kernel.org>
Acked-by: Waiman Long <longman@redhat.com>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Signed-off-by: Waiman Long <longman@redhat.com>
Reviewed-by: Chen Ridong <chenridong@huaweicloud.com>
---
kernel/cgroup/cpuset.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 27adb04df675..cf34623fe66f 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1339,7 +1339,7 @@ static bool partition_xcpus_del(int old_prs, struct cpuset *parent,
return isolcpus_updated;
}
-static void update_unbound_workqueue_cpumask(bool isolcpus_updated)
+static void update_isolation_cpumasks(bool isolcpus_updated)
{
int ret;
@@ -1470,7 +1470,7 @@ static int remote_partition_enable(struct cpuset *cs, int new_prs,
list_add(&cs->remote_sibling, &remote_children);
cpumask_copy(cs->effective_xcpus, tmp->new_cpus);
spin_unlock_irq(&callback_lock);
- update_unbound_workqueue_cpumask(isolcpus_updated);
+ update_isolation_cpumasks(isolcpus_updated);
cpuset_force_rebuild();
cs->prs_err = 0;
@@ -1511,7 +1511,7 @@ static void remote_partition_disable(struct cpuset *cs, struct tmpmasks *tmp)
compute_effective_exclusive_cpumask(cs, NULL, NULL);
reset_partition_data(cs);
spin_unlock_irq(&callback_lock);
- update_unbound_workqueue_cpumask(isolcpus_updated);
+ update_isolation_cpumasks(isolcpus_updated);
cpuset_force_rebuild();
/*
@@ -1580,7 +1580,7 @@ static void remote_cpus_update(struct cpuset *cs, struct cpumask *xcpus,
if (xcpus)
cpumask_copy(cs->exclusive_cpus, xcpus);
spin_unlock_irq(&callback_lock);
- update_unbound_workqueue_cpumask(isolcpus_updated);
+ update_isolation_cpumasks(isolcpus_updated);
if (adding || deleting)
cpuset_force_rebuild();
@@ -1943,7 +1943,7 @@ static int update_parent_effective_cpumask(struct cpuset *cs, int cmd,
WARN_ON_ONCE(parent->nr_subparts < 0);
}
spin_unlock_irq(&callback_lock);
- update_unbound_workqueue_cpumask(isolcpus_updated);
+ update_isolation_cpumasks(isolcpus_updated);
if ((old_prs != new_prs) && (cmd == partcmd_update))
update_partition_exclusive_flag(cs, new_prs);
@@ -2968,7 +2968,7 @@ static int update_prstate(struct cpuset *cs, int new_prs)
else if (isolcpus_updated)
isolated_cpus_update(old_prs, new_prs, cs->effective_xcpus);
spin_unlock_irq(&callback_lock);
- update_unbound_workqueue_cpumask(isolcpus_updated);
+ update_isolation_cpumasks(isolcpus_updated);
/* Force update if switching back to member & update effective_xcpus */
update_cpumasks_hier(cs, &tmpmask, !new_prs);
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v15 5/7] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
` (3 preceding siblings ...)
2025-11-13 8:33 ` [PATCH v15 4/7] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_isolation_cpumasks() Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 6/7] cpumask: Add initialiser to use cleanup helpers Gabriele Monaco
` (2 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco
Currently the user can set up isolcpus and nohz_full in such a way that
leaves no housekeeping CPU (i.e. no CPU that is neither domain isolated
nor nohz full). This can be a problem for other subsystems (e.g. the
timer wheel imgration).
Prevent this configuration by invalidating the last setting in case the
union of isolcpus (domain) and nohz_full covers all CPUs.
Reviewed-by: Waiman Long <longman@redhat.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
kernel/sched/isolation.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index a4cf17b1fab0..3ad0d6df6a0a 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -167,6 +167,29 @@ static int __init housekeeping_setup(char *str, unsigned long flags)
}
}
+ /*
+ * Check the combination of nohz_full and isolcpus=domain,
+ * necessary to avoid problems with the timer migration
+ * hierarchy. managed_irq is ignored by this check since it
+ * isn't considered in the timer migration logic.
+ */
+ iter_flags = housekeeping.flags & (HK_FLAG_KERNEL_NOISE | HK_FLAG_DOMAIN);
+ type = find_first_bit(&iter_flags, HK_TYPE_MAX);
+ /*
+ * Pass the check if none of these flags were previously set or
+ * are not in the current selection.
+ */
+ iter_flags = flags & (HK_FLAG_KERNEL_NOISE | HK_FLAG_DOMAIN);
+ first_cpu = (type == HK_TYPE_MAX || !iter_flags) ? 0 :
+ cpumask_first_and_and(cpu_present_mask,
+ housekeeping_staging, housekeeping.cpumasks[type]);
+ if (first_cpu >= min(nr_cpu_ids, setup_max_cpus)) {
+ pr_warn("Housekeeping: must include one present CPU "
+ "neither in nohz_full= nor in isolcpus=domain, "
+ "ignoring setting %s\n", str);
+ goto free_housekeeping_staging;
+ }
+
iter_flags = flags & ~housekeeping.flags;
for_each_set_bit(type, &iter_flags, HK_TYPE_MAX)
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v15 6/7] cpumask: Add initialiser to use cleanup helpers
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
` (4 preceding siblings ...)
2025-11-13 8:33 ` [PATCH v15 5/7] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-13 8:33 ` [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-11-13 13:12 ` [PATCH v15 0/7] " Frederic Weisbecker
7 siblings, 0 replies; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Yury Norov, Gabriele Monaco
From: Yury Norov <yury.norov@gmail.com>
Now we can simplify a code that allocates cpumasks for local needs.
Automatic variables have to be initialized at declaration, or at least
before any possibility for the logic to return, so that compiler
wouldn't try to call an associate destructor function on a random stack
number.
Because cpumask_var_t, depending on the CPUMASK_OFFSTACK config, is
either a pointer or an array, we have to have a macro for initialization.
So define a CPUMASK_VAR_NULL macro, which allows to init struct cpumask
pointer with NULL when CPUMASK_OFFSTACK is enabled, and effectively a
no-op when CPUMASK_OFFSTACK is disabled (initialisation optimised out
with -O2).
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
---
include/linux/cpumask.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index ff8f41ab7ce6..68be522449ec 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -1005,6 +1005,7 @@ static __always_inline unsigned int cpumask_size(void)
#define this_cpu_cpumask_var_ptr(x) this_cpu_read(x)
#define __cpumask_var_read_mostly __read_mostly
+#define CPUMASK_VAR_NULL NULL
bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
@@ -1051,6 +1052,7 @@ static __always_inline bool cpumask_available(cpumask_var_t mask)
#define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x)
#define __cpumask_var_read_mostly
+#define CPUMASK_VAR_NULL {}
static __always_inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
{
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
` (5 preceding siblings ...)
2025-11-13 8:33 ` [PATCH v15 6/7] cpumask: Add initialiser to use cleanup helpers Gabriele Monaco
@ 2025-11-13 8:33 ` Gabriele Monaco
2025-11-19 16:50 ` Thomas Gleixner
2025-11-19 20:43 ` Waiman Long
2025-11-13 13:12 ` [PATCH v15 0/7] " Frederic Weisbecker
7 siblings, 2 replies; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-13 8:33 UTC (permalink / raw)
To: linux-kernel, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Waiman Long
Cc: Gabriele Monaco, John B. Wyatt IV, John B. Wyatt IV
The timer migration mechanism allows active CPUs to pull timers from
idle ones to improve the overall idle time. This is however undesired
when CPU intensive workloads run on isolated cores, as the algorithm
would move the timers from housekeeping to isolated cores, negatively
affecting the isolation.
Exclude isolated cores from the timer migration algorithm, extend the
concept of unavailable cores, currently used for offline ones, to
isolated ones:
* A core is unavailable if isolated or offline;
* A core is available if non isolated and online;
A core is considered unavailable as isolated if it belongs to:
* the isolcpus (domain) list
* an isolated cpuset
Except if it is:
* in the nohz_full list (already idle for the hierarchy)
* the nohz timekeeper core (must be available to handle global timers)
CPUs are added to the hierarchy during late boot, excluding isolated
ones, the hierarchy is also adapted when the cpuset isolation changes.
Due to how the timer migration algorithm works, any CPU part of the
hierarchy can have their global timers pulled by remote CPUs and have to
pull remote timers, only skipping pulling remote timers would break the
logic.
For this reason, prevent isolated CPUs from pulling remote global
timers, but also the other way around: any global timer started on an
isolated CPU will run there. This does not break the concept of
isolation (global timers don't come from outside the CPU) and, if
considered inappropriate, can usually be mitigated with other isolation
techniques (e.g. IRQ pinning).
This effect was noticed on a 128 cores machine running oslat on the
isolated cores (1-31,33-63,65-95,97-127). The tool monopolises CPUs,
and the CPU with lowest count in a timer migration hierarchy (here 1
and 65) appears as always active and continuously pulls global timers,
from the housekeeping CPUs. This ends up moving driver work (e.g.
delayed work) to isolated CPUs and causes latency spikes:
before the change:
# oslat -c 1-31,33-63,65-95,97-127 -D 62s
...
Maximum: 1203 10 3 4 ... 5 (us)
after the change:
# oslat -c 1-31,33-63,65-95,97-127 -D 62s
...
Maximum: 10 4 3 4 3 ... 5 (us)
The same behaviour was observed on a machine with as few as 20 cores /
40 threads with isocpus set to: 1-9,11-39 with rtla-osnoise-top.
Tested-by: John B. Wyatt IV <jwyatt@redhat.com>
Tested-by: John B. Wyatt IV <sageofredondo@gmail.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
include/linux/timer.h | 9 ++
kernel/cgroup/cpuset.c | 3 +
kernel/time/timer_migration.c | 156 ++++++++++++++++++++++++++++++++--
3 files changed, 163 insertions(+), 5 deletions(-)
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 0414d9e6b4fc..62e1cea71125 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -188,4 +188,13 @@ int timers_dead_cpu(unsigned int cpu);
#define timers_dead_cpu NULL
#endif
+#if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
+extern int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask);
+#else
+static inline int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
+{
+ return 0;
+}
+#endif
+
#endif
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index cf34623fe66f..bfc3b319e1c0 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1350,6 +1350,9 @@ static void update_isolation_cpumasks(bool isolcpus_updated)
ret = workqueue_unbound_exclude_cpumask(isolated_cpus);
WARN_ON_ONCE(ret < 0);
+
+ ret = tmigr_isolated_exclude_cpumask(isolated_cpus);
+ WARN_ON_ONCE(ret < 0);
}
/**
diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
index d3eb9714e692..0e275d526d50 100644
--- a/kernel/time/timer_migration.c
+++ b/kernel/time/timer_migration.c
@@ -10,6 +10,7 @@
#include <linux/spinlock.h>
#include <linux/timerqueue.h>
#include <trace/events/ipi.h>
+#include <linux/sched/isolation.h>
#include "timer_migration.h"
#include "tick-internal.h"
@@ -430,6 +431,9 @@ static DEFINE_PER_CPU(struct tmigr_cpu, tmigr_cpu);
*/
static cpumask_var_t tmigr_available_cpumask;
+/* Enabled during late initcall */
+static DEFINE_STATIC_KEY_FALSE(tmigr_exclude_isolated);
+
#define TMIGR_NONE 0xFF
#define BIT_CNT 8
@@ -438,6 +442,33 @@ static inline bool tmigr_is_not_available(struct tmigr_cpu *tmc)
return !(tmc->tmgroup && tmc->available);
}
+/*
+ * Returns true if @cpu should be excluded from the hierarchy as isolated.
+ * Domain isolated CPUs don't participate in timer migration, nohz_full CPUs
+ * are still part of the hierarchy but become idle (from a tick and timer
+ * migration perspective) when they stop their tick. This lets the timekeeping
+ * CPU handle their global timers. Marking also isolated CPUs as idle would be
+ * too costly, hence they are completely excluded from the hierarchy.
+ * This check is necessary, for instance, to prevent offline isolated CPUs from
+ * being incorrectly marked as available once getting back online.
+ *
+ * This function returns false during early boot and the isolation logic is
+ * enabled only after isolated CPUs are marked as unavailable at late boot.
+ * The tick CPU can be isolated at boot, however we cannot mark it as
+ * unavailable to avoid having no global migrator for the nohz_full CPUs. This
+ * should be ensured by the callers of this function: implicitly from hotplug
+ * callbacs and explicitly in tmigr_init_isolation and
+ * tmigr_isolated_exclude_cpumask.
+ */
+static inline bool tmigr_is_isolated(int cpu)
+{
+ if (static_branch_unlikely(&tmigr_exclude_isolated))
+ return (!housekeeping_cpu(cpu, HK_TYPE_DOMAIN) ||
+ cpuset_cpu_is_isolated(cpu)) &&
+ housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE);
+ return false;
+}
+
/*
* Returns true, when @childmask corresponds to the group migrator or when the
* group is not active - so no migrator is set.
@@ -1439,8 +1470,9 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
int migrator;
u64 firstexp;
- cpumask_clear_cpu(cpu, tmigr_available_cpumask);
scoped_guard(raw_spinlock_irq, &tmc->lock) {
+ if (!tmc->available)
+ return 0;
tmc->available = false;
WRITE_ONCE(tmc->wakeup, KTIME_MAX);
@@ -1453,11 +1485,11 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
}
if (firstexp != KTIME_MAX) {
- migrator = cpumask_any(tmigr_available_cpumask);
+ migrator = cpumask_any_but(tmigr_available_cpumask, cpu);
work_on_cpu(migrator, tmigr_trigger_active, NULL);
}
- return 0;
+ return 1;
}
static int tmigr_set_cpu_available(unsigned int cpu)
@@ -1468,17 +1500,130 @@ static int tmigr_set_cpu_available(unsigned int cpu)
if (WARN_ON_ONCE(!tmc->tmgroup))
return -EINVAL;
- cpumask_set_cpu(cpu, tmigr_available_cpumask);
+ if (tmigr_is_isolated(cpu))
+ return 0;
+
scoped_guard(raw_spinlock_irq, &tmc->lock) {
+ if (tmc->available)
+ return 0;
trace_tmigr_cpu_available(tmc);
tmc->idle = timer_base_is_idle();
if (!tmc->idle)
__tmigr_cpu_activate(tmc);
tmc->available = true;
}
+ return 1;
+}
+
+static int tmigr_online_cpu(unsigned int cpu)
+{
+ if (tmigr_set_cpu_available(cpu) > 0)
+ cpumask_set_cpu(cpu, tmigr_available_cpumask);
+ return 0;
+}
+
+static int tmigr_offline_cpu(unsigned int cpu)
+{
+ if (tmigr_clear_cpu_available(cpu) > 0)
+ cpumask_clear_cpu(cpu, tmigr_available_cpumask);
+ return 0;
+}
+
+static void tmigr_cpu_isolate(struct work_struct *ignored)
+{
+ tmigr_clear_cpu_available(smp_processor_id());
+}
+
+static void tmigr_cpu_unisolate(struct work_struct *ignored)
+{
+ tmigr_set_cpu_available(smp_processor_id());
+}
+
+static int __tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
+{
+ struct work_struct __percpu *works __free(free_percpu) =
+ alloc_percpu(struct work_struct);
+ cpumask_var_t cpumask_unisol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
+ cpumask_var_t cpumask_isol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
+ int cpu;
+
+ if (!alloc_cpumask_var(&cpumask_isol, GFP_KERNEL))
+ return -ENOMEM;
+ if (!alloc_cpumask_var(&cpumask_unisol, GFP_KERNEL))
+ return -ENOMEM;
+ if (!works)
+ return -ENOMEM;
+
+ cpumask_andnot(cpumask_unisol, cpu_online_mask, exclude_cpumask);
+ cpumask_andnot(cpumask_unisol, cpumask_unisol, tmigr_available_cpumask);
+ /* Set up the mask earlier to avoid races with the migrator CPU */
+ cpumask_or(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_unisol);
+ for_each_cpu(cpu, cpumask_unisol) {
+ struct work_struct *work = per_cpu_ptr(works, cpu);
+
+ INIT_WORK(work, tmigr_cpu_unisolate);
+ schedule_work_on(cpu, work);
+ }
+
+ cpumask_and(cpumask_isol, exclude_cpumask, tmigr_available_cpumask);
+ cpumask_and(cpumask_isol, cpumask_isol, housekeeping_cpumask(HK_TYPE_KERNEL_NOISE));
+ /*
+ * Handle this here and not in the cpuset code because exclude_cpumask
+ * might include also the tick CPU if included in isolcpus.
+ */
+ for_each_cpu(cpu, cpumask_isol) {
+ if (!tick_nohz_cpu_hotpluggable(cpu)) {
+ cpumask_clear_cpu(cpu, cpumask_isol);
+ break;
+ }
+ }
+ /* Set up the mask earlier to avoid races with the migrator CPU */
+ cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
+ for_each_cpu(cpu, cpumask_isol) {
+ struct work_struct *work = per_cpu_ptr(works, cpu);
+
+ INIT_WORK(work, tmigr_cpu_isolate);
+ schedule_work_on(cpu, work);
+ }
+
+ for_each_cpu_or(cpu, cpumask_isol, cpumask_unisol)
+ flush_work(per_cpu_ptr(works, cpu));
+
return 0;
}
+/**
+ * tmigr_isolated_exclude_cpumask - Exclude given CPUs from hierarchy
+ * @exclude_cpumask: the cpumask to be excluded from timer migration hierarchy
+ *
+ * This function can be called from cpuset code to provide the new set of
+ * isolated CPUs that should be excluded from the hierarchy.
+ * Online CPUs not present in exclude_cpumask but already excluded are brought
+ * back to the hierarchy.
+ * Functions to isolate/unisolate need to be called locally and can sleep.
+ */
+int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
+{
+ lockdep_assert_cpus_held();
+ return __tmigr_isolated_exclude_cpumask(exclude_cpumask);
+}
+
+static int __init tmigr_init_isolation(void)
+{
+ cpumask_var_t cpumask __free(free_cpumask_var) = CPUMASK_VAR_NULL;
+
+ static_branch_enable(&tmigr_exclude_isolated);
+
+ if (!housekeeping_enabled(HK_TYPE_DOMAIN))
+ return 0;
+ if (!alloc_cpumask_var(&cpumask, GFP_KERNEL))
+ return -ENOMEM;
+
+ cpumask_andnot(cpumask, cpu_possible_mask, housekeeping_cpumask(HK_TYPE_DOMAIN));
+
+ return __tmigr_isolated_exclude_cpumask(cpumask);
+}
+
static void tmigr_init_group(struct tmigr_group *group, unsigned int lvl,
int node)
{
@@ -1867,7 +2012,7 @@ static int __init tmigr_init(void)
goto err;
ret = cpuhp_setup_state(CPUHP_AP_TMIGR_ONLINE, "tmigr:online",
- tmigr_set_cpu_available, tmigr_clear_cpu_available);
+ tmigr_online_cpu, tmigr_offline_cpu);
if (ret)
goto err;
@@ -1878,3 +2023,4 @@ static int __init tmigr_init(void)
return ret;
}
early_initcall(tmigr_init);
+late_initcall(tmigr_init_isolation);
--
2.51.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-13 8:33 ` [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
@ 2025-11-19 16:50 ` Thomas Gleixner
2025-11-19 17:14 ` Frederic Weisbecker
2025-11-19 20:43 ` Waiman Long
1 sibling, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 16:50 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Waiman Long
Cc: Gabriele Monaco, John B. Wyatt IV, John B. Wyatt IV
On Thu, Nov 13 2025 at 09:33, Gabriele Monaco wrote:
> +/* Enabled during late initcall */
> +static DEFINE_STATIC_KEY_FALSE(tmigr_exclude_isolated);
> +
> #define TMIGR_NONE 0xFF
> #define BIT_CNT 8
>
> @@ -438,6 +442,33 @@ static inline bool tmigr_is_not_available(struct tmigr_cpu *tmc)
> return !(tmc->tmgroup && tmc->available);
> }
>
> +/*
> + * Returns true if @cpu should be excluded from the hierarchy as isolated.
> + * Domain isolated CPUs don't participate in timer migration, nohz_full CPUs
> + * are still part of the hierarchy but become idle (from a tick and timer
> + * migration perspective) when they stop their tick. This lets the timekeeping
> + * CPU handle their global timers. Marking also isolated CPUs as idle would be
> + * too costly, hence they are completely excluded from the hierarchy.
> + * This check is necessary, for instance, to prevent offline isolated CPUs from
> + * being incorrectly marked as available once getting back online.
> + *
> + * This function returns false during early boot and the isolation logic is
> + * enabled only after isolated CPUs are marked as unavailable at late boot.
> + * The tick CPU can be isolated at boot, however we cannot mark it as
> + * unavailable to avoid having no global migrator for the nohz_full CPUs. This
> + * should be ensured by the callers of this function: implicitly from hotplug
> + * callbacs and explicitly in tmigr_init_isolation and
callbacks tmigr_init_isolation()
> + * tmigr_isolated_exclude_cpumask.
tmigr_isolated_exclude_cpumask() It's documented how functions should be
denoted in comments and change logs, no?
> + */
> +static inline bool tmigr_is_isolated(int cpu)
> +{
> + if (static_branch_unlikely(&tmigr_exclude_isolated))
> + return (!housekeeping_cpu(cpu, HK_TYPE_DOMAIN) ||
> + cpuset_cpu_is_isolated(cpu)) &&
> + housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE);
Lacks brackets on the if ()
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#bracket-rules
Also you can make this way more readable by inverting the condition:
if (!static_branch_unlikely(&tmigr_exclude_isolated))
return false;
return .....;
No?
> + return false;
> +}
> +
> /*
> * Returns true, when @childmask corresponds to the group migrator or when the
> * group is not active - so no migrator is set.
> @@ -1439,8 +1470,9 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
> int migrator;
> u64 firstexp;
>
> - cpumask_clear_cpu(cpu, tmigr_available_cpumask);
By removing this the function name does not make any sense any
more. Splitting the cpumask_clear_set() out, renaming the function
> scoped_guard(raw_spinlock_irq, &tmc->lock) {
> + if (!tmc->available)
> + return 0;
and adding this
> tmc->available = false;
> WRITE_ONCE(tmc->wakeup, KTIME_MAX);
>
> @@ -1453,11 +1485,11 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
> }
>
> if (firstexp != KTIME_MAX) {
> - migrator = cpumask_any(tmigr_available_cpumask);
> + migrator = cpumask_any_but(tmigr_available_cpumask, cpu);
and this should be done in a preparatory patch along with a
reasonable explanation in the change log.
> work_on_cpu(migrator, tmigr_trigger_active, NULL);
> }
>
> - return 0;
> + return 1;
But thinking more about it. What's the actual point of moving this 'clear'
out instead of just moving it further down?
It does not matter at all whether the isol/unisol muck clears an already
cleared bit or not. But it would keep the function name comprehensible
and avoid all this online/offline wrapper nonsense.
> }
>
> static int tmigr_set_cpu_available(unsigned int cpu)
> @@ -1468,17 +1500,130 @@ static int tmigr_set_cpu_available(unsigned int cpu)
> if (WARN_ON_ONCE(!tmc->tmgroup))
> return -EINVAL;
>
> - cpumask_set_cpu(cpu, tmigr_available_cpumask);
Ditto.
> +static int __tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> +{
> + struct work_struct __percpu *works __free(free_percpu) =
> + alloc_percpu(struct work_struct);
> + cpumask_var_t cpumask_unisol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> + cpumask_var_t cpumask_isol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> + int cpu;
> +
> + if (!alloc_cpumask_var(&cpumask_isol, GFP_KERNEL))
> + return -ENOMEM;
> + if (!alloc_cpumask_var(&cpumask_unisol, GFP_KERNEL))
> + return -ENOMEM;
> + if (!works)
> + return -ENOMEM;
Checking the first allocation after trying to allocate other stuff makes
a lot of sense - NOT.
> + cpumask_andnot(cpumask_unisol, cpu_online_mask, exclude_cpumask);
> + cpumask_andnot(cpumask_unisol, cpumask_unisol, tmigr_available_cpumask);
> + /* Set up the mask earlier to avoid races with the migrator CPU */
> + cpumask_or(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_unisol);
Your new line key is broken. This comment is barely noticeable. What's
worse is that it completely fails to explain what the actual race is.
> + for_each_cpu(cpu, cpumask_unisol) {
> + struct work_struct *work = per_cpu_ptr(works, cpu);
> +
> + INIT_WORK(work, tmigr_cpu_unisolate);
> + schedule_work_on(cpu, work);
> + }
> +
> + cpumask_and(cpumask_isol, exclude_cpumask, tmigr_available_cpumask);
> + cpumask_and(cpumask_isol, cpumask_isol, housekeeping_cpumask(HK_TYPE_KERNEL_NOISE));
> + /*
> + * Handle this here and not in the cpuset code because exclude_cpumask
> + * might include also the tick CPU if included in isolcpus.
> + */
> + for_each_cpu(cpu, cpumask_isol) {
> + if (!tick_nohz_cpu_hotpluggable(cpu)) {
> + cpumask_clear_cpu(cpu, cpumask_isol);
> + break;
> + }
> + }
> + /* Set up the mask earlier to avoid races with the migrator CPU */
> + cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
> + for_each_cpu(cpu, cpumask_isol) {
> + struct work_struct *work = per_cpu_ptr(works, cpu);
This lacks a comment explaining that cpumask_unisol and _isol are not
overlapping. I had to stare at this five times to convince myself that
it's correct.
> +
> + INIT_WORK(work, tmigr_cpu_isolate);
> + schedule_work_on(cpu, work);
> + }
> +
> + for_each_cpu_or(cpu, cpumask_isol, cpumask_unisol)
> + flush_work(per_cpu_ptr(works, cpu));
> +
> return 0;
> }
>
> +/**
> + * tmigr_isolated_exclude_cpumask - Exclude given CPUs from hierarchy
> + * @exclude_cpumask: the cpumask to be excluded from timer migration hierarchy
> + *
> + * This function can be called from cpuset code to provide the new set of
> + * isolated CPUs that should be excluded from the hierarchy.
> + * Online CPUs not present in exclude_cpumask but already excluded are brought
> + * back to the hierarchy.
> + * Functions to isolate/unisolate need to be called locally and can sleep.
> + */
> +int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> +{
> + lockdep_assert_cpus_held();
> + return __tmigr_isolated_exclude_cpumask(exclude_cpumask);
This wrapper is required because...
> +}
> +
> +static int __init tmigr_init_isolation(void)
> +{
> + cpumask_var_t cpumask __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> +
> + static_branch_enable(&tmigr_exclude_isolated);
> +
> + if (!housekeeping_enabled(HK_TYPE_DOMAIN))
> + return 0;
> + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + cpumask_andnot(cpumask, cpu_possible_mask, housekeeping_cpumask(HK_TYPE_DOMAIN));
... it would be too sensible to guard this with:
guard(cpus_read_lock)();
for consistency sake _AND_ what's more important to protect it against
the RCU torture test code which plays with CPU hotplug starting in
device_initcall(), which runs before
> +late_initcall(tmigr_init_isolation);
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 16:50 ` Thomas Gleixner
@ 2025-11-19 17:14 ` Frederic Weisbecker
2025-11-19 18:15 ` Thomas Gleixner
0 siblings, 1 reply; 24+ messages in thread
From: Frederic Weisbecker @ 2025-11-19 17:14 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit :
> On Thu, Nov 13 2025 at 09:33, Gabriele Monaco wrote:
> > - cpumask_clear_cpu(cpu, tmigr_available_cpumask);
>
> By removing this the function name does not make any sense any
> more. Splitting the cpumask_clear_set() out, renaming the function
>
> > scoped_guard(raw_spinlock_irq, &tmc->lock) {
> > + if (!tmc->available)
> > + return 0;
>
> and adding this
>
> > tmc->available = false;
> > WRITE_ONCE(tmc->wakeup, KTIME_MAX);
> >
> > @@ -1453,11 +1485,11 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
> > }
> >
> > if (firstexp != KTIME_MAX) {
> > - migrator = cpumask_any(tmigr_available_cpumask);
> > + migrator = cpumask_any_but(tmigr_available_cpumask, cpu);
>
> and this should be done in a preparatory patch along with a
> reasonable explanation in the change log.
>
> > work_on_cpu(migrator, tmigr_trigger_active, NULL);
> > }
> >
> > - return 0;
> > + return 1;
>
> But thinking more about it. What's the actual point of moving this 'clear'
> out instead of just moving it further down?
>
> It does not matter at all whether the isol/unisol muck clears an already
> cleared bit or not. But it would keep the function name comprehensible
> and avoid all this online/offline wrapper nonsense.
That was my suggestion.
It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available()
can now all be called concurrently through the workqueues and race and
mess up the cpumask if they all try to clear/set at the same time...
And I couldn't find a saner way to order things...
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 17:14 ` Frederic Weisbecker
@ 2025-11-19 18:15 ` Thomas Gleixner
2025-11-19 20:13 ` Frederic Weisbecker
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 18:15 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
On Wed, Nov 19 2025 at 18:14, Frederic Weisbecker wrote:
> Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit :
>> But thinking more about it. What's the actual point of moving this 'clear'
>> out instead of just moving it further down?
>>
>> It does not matter at all whether the isol/unisol muck clears an already
>> cleared bit or not. But it would keep the function name comprehensible
>> and avoid all this online/offline wrapper nonsense.
>
> That was my suggestion.
>
> It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available()
> can now all be called concurrently through the workqueues and race and
> mess up the cpumask if they all try to clear/set at the same time...
Huch?
cpumask_set_cpu() uses set_bit() and cpumask_clear_cpu() uses
clear_bit(). Both are atomic and nothing gets messed up.
The only undefined case would be if you end up setting/clearing the same
bit, which would require that the unisol and isol maps overlap. But that
would be a bug on it's own, no?
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 18:15 ` Thomas Gleixner
@ 2025-11-19 20:13 ` Frederic Weisbecker
2025-11-19 21:23 ` Thomas Gleixner
0 siblings, 1 reply; 24+ messages in thread
From: Frederic Weisbecker @ 2025-11-19 20:13 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
Le Wed, Nov 19, 2025 at 07:15:42PM +0100, Thomas Gleixner a écrit :
> On Wed, Nov 19 2025 at 18:14, Frederic Weisbecker wrote:
> > Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit :
> >> But thinking more about it. What's the actual point of moving this 'clear'
> >> out instead of just moving it further down?
> >>
> >> It does not matter at all whether the isol/unisol muck clears an already
> >> cleared bit or not. But it would keep the function name comprehensible
> >> and avoid all this online/offline wrapper nonsense.
> >
> > That was my suggestion.
> >
> > It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available()
> > can now all be called concurrently through the workqueues and race and
> > mess up the cpumask if they all try to clear/set at the same time...
>
> Huch?
>
> cpumask_set_cpu() uses set_bit() and cpumask_clear_cpu() uses
> clear_bit(). Both are atomic and nothing gets messed up.
Urgh, right...
>
> The only undefined case would be if you end up setting/clearing the same
> bit, which would require that the unisol and isol maps overlap. But that
> would be a bug on it's own, no?
Ok.
But then the "unisolate" works must be flushed before this line:
+ /* Set up the mask earlier to avoid races with the migrator CPU */
+ cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
Because that is non-atomic and can race with the cpumask_set_cpu() from the
works, right?
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 20:13 ` Frederic Weisbecker
@ 2025-11-19 21:23 ` Thomas Gleixner
2025-11-19 22:02 ` Frederic Weisbecker
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 21:23 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
On Wed, Nov 19 2025 at 21:13, Frederic Weisbecker wrote:
> Le Wed, Nov 19, 2025 at 07:15:42PM +0100, Thomas Gleixner a écrit :
>> On Wed, Nov 19 2025 at 18:14, Frederic Weisbecker wrote:
>> > Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit :
>> >> But thinking more about it. What's the actual point of moving this 'clear'
>> >> out instead of just moving it further down?
>> >>
>> >> It does not matter at all whether the isol/unisol muck clears an already
>> >> cleared bit or not. But it would keep the function name comprehensible
>> >> and avoid all this online/offline wrapper nonsense.
>> >
>> > That was my suggestion.
>> >
>> > It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available()
>> > can now all be called concurrently through the workqueues and race and
>> > mess up the cpumask if they all try to clear/set at the same time...
>>
>> Huch?
>>
>> cpumask_set_cpu() uses set_bit() and cpumask_clear_cpu() uses
>> clear_bit(). Both are atomic and nothing gets messed up.
>
> Urgh, right...
>
>>
>> The only undefined case would be if you end up setting/clearing the same
>> bit, which would require that the unisol and isol maps overlap. But that
>> would be a bug on it's own, no?
>
> Ok.
>
> But then the "unisolate" works must be flushed before this line:
>
> + /* Set up the mask earlier to avoid races with the migrator CPU */
> + cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
>
> Because that is non-atomic and can race with the cpumask_set_cpu() from the
> works, right?
Correct, but I still have to understand why this has to happen
upfront. As I said before this comment is useless:
> + /* Set up the mask earlier to avoid races with the migrator CPU */
which decodes to:
Set up the mask earlier than something unspecified to avoid
unspecified races with the migrator CPU.
Seriously?
But I finally understood what this is about after staring at it with
less disgust again for five times in a row:
tmigr_clear_cpu_available() requires a stable cpumask to find a
migrator.
So what this is about is to avoid touching the cpumask in those worker
functions so that tmigr_isolated_exclude_cpumask() can fiddle with them
asynchronously.
Right?
That's voodoo programming which nobody - even those involved - will
understand anymore three months down the road.
The idea that updating the masks upfront will provide stable state is
flawed to begin with. Let's assume the following scenario:
1) The isol/unisol mask is just flipped around
2) The newly available CPUs are marked in the mask
3) The work is scheduled on those CPUs
4) The newly unavailable CPUs are cleared in the mask
5) The work is scheduled on those CPUs
6) The newly available CPU workers are delayed so that the newly
unavailable workers get there first. They find a stable CPU mask,
but none of these now "available" CPUs are actually brought into
active state yet.
That's just a perfect recipe for some completely undecodable bug to
happen anytime soon even it it supposed to "work" by chance.
The way how this was designed in the first place is that changing the
"availability" is fully serialized by the CPU hotplug machinery. Which
means zero surprises.
Now you create a side channel, which lacks these serialization
guarantees for absolutely no reason. Changing this isolation muck at
run-time is not a hotpath operation and trying to optimize it for no
good reason is just stupid.
The most trivial solution is to schedule the works one by one walking
through the newly available and then through the unavailable maps.
If you want to be a bit smarter, then you can just use a global mutex,
which is taken inside the set/clear_available() functions which
serializes the related functionality and bulk schedule/flush the unisol
(make available) first and then proceed to the isol (make unavailable).
Then nothing has to change vs. the set/clear operations and everything
just works.
That mutex does not do any harm in the CPU hotplug case and the
serialization vs. the workers is not going to be the end of the world.
I'm willing to bet that no real-world use-case will ever notice the
existance of this mutex. The microbenchmark which shows off the "I'm so
smart" metric is completely irrelevant especially when the result is
fragile, incomprehensible and therefore unmaintainable.
Keep it correct and simple is still the most important engineering
principle. Premature optimization is a guaranteed path to failure.
If there is a compelling use case which justifies the resulting
complexity, then it can be built on top. I'm not holding my breath. See
above...
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 21:23 ` Thomas Gleixner
@ 2025-11-19 22:02 ` Frederic Weisbecker
2025-11-19 22:10 ` Thomas Gleixner
0 siblings, 1 reply; 24+ messages in thread
From: Frederic Weisbecker @ 2025-11-19 22:02 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a écrit :
> On Wed, Nov 19 2025 at 21:13, Frederic Weisbecker wrote:
> > Le Wed, Nov 19, 2025 at 07:15:42PM +0100, Thomas Gleixner a écrit :
> >> On Wed, Nov 19 2025 at 18:14, Frederic Weisbecker wrote:
> >> > Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit :
> >> >> But thinking more about it. What's the actual point of moving this 'clear'
> >> >> out instead of just moving it further down?
> >> >>
> >> >> It does not matter at all whether the isol/unisol muck clears an already
> >> >> cleared bit or not. But it would keep the function name comprehensible
> >> >> and avoid all this online/offline wrapper nonsense.
> >> >
> >> > That was my suggestion.
> >> >
> >> > It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available()
> >> > can now all be called concurrently through the workqueues and race and
> >> > mess up the cpumask if they all try to clear/set at the same time...
> >>
> >> Huch?
> >>
> >> cpumask_set_cpu() uses set_bit() and cpumask_clear_cpu() uses
> >> clear_bit(). Both are atomic and nothing gets messed up.
> >
> > Urgh, right...
> >
> >>
> >> The only undefined case would be if you end up setting/clearing the same
> >> bit, which would require that the unisol and isol maps overlap. But that
> >> would be a bug on it's own, no?
> >
> > Ok.
> >
> > But then the "unisolate" works must be flushed before this line:
> >
> > + /* Set up the mask earlier to avoid races with the migrator CPU */
> > + cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
> >
> > Because that is non-atomic and can race with the cpumask_set_cpu() from the
> > works, right?
>
> Correct, but I still have to understand why this has to happen
> upfront. As I said before this comment is useless:
>
> > + /* Set up the mask earlier to avoid races with the migrator CPU */
>
> which decodes to:
>
> Set up the mask earlier than something unspecified to avoid
> unspecified races with the migrator CPU.
>
> Seriously?
>
> But I finally understood what this is about after staring at it with
> less disgust again for five times in a row:
>
> tmigr_clear_cpu_available() requires a stable cpumask to find a
> migrator.
>
> So what this is about is to avoid touching the cpumask in those worker
> functions so that tmigr_isolated_exclude_cpumask() can fiddle with them
> asynchronously.
>
> Right?
>
> That's voodoo programming which nobody - even those involved - will
> understand anymore three months down the road.
>
> The idea that updating the masks upfront will provide stable state is
> flawed to begin with. Let's assume the following scenario:
>
> 1) The isol/unisol mask is just flipped around
>
> 2) The newly available CPUs are marked in the mask
>
> 3) The work is scheduled on those CPUs
>
> 4) The newly unavailable CPUs are cleared in the mask
>
> 5) The work is scheduled on those CPUs
>
> 6) The newly available CPU workers are delayed so that the newly
> unavailable workers get there first. They find a stable CPU mask,
> but none of these now "available" CPUs are actually brought into
> active state yet.
>
> That's just a perfect recipe for some completely undecodable bug to
> happen anytime soon even it it supposed to "work" by chance.
Urgh, indeed I completely missed that...
>
> The way how this was designed in the first place is that changing the
> "availability" is fully serialized by the CPU hotplug machinery. Which
> means zero surprises.
>
> Now you create a side channel, which lacks these serialization
> guarantees for absolutely no reason. Changing this isolation muck at
> run-time is not a hotpath operation and trying to optimize it for no
> good reason is just stupid.
>
> The most trivial solution is to schedule the works one by one walking
> through the newly available and then through the unavailable maps.
Right.
>
> If you want to be a bit smarter, then you can just use a global mutex,
> which is taken inside the set/clear_available() functions which
> serializes the related functionality and bulk schedule/flush the unisol
> (make available) first and then proceed to the isol (make unavailable).
>
> Then nothing has to change vs. the set/clear operations and everything
> just works.
>
> That mutex does not do any harm in the CPU hotplug case and the
> serialization vs. the workers is not going to be the end of the world.
>
> I'm willing to bet that no real-world use-case will ever notice the
> existance of this mutex. The microbenchmark which shows off the "I'm so
> smart" metric is completely irrelevant especially when the result is
> fragile, incomprehensible and therefore unmaintainable.
>
> Keep it correct and simple is still the most important engineering
> principle. Premature optimization is a guaranteed path to failure.
>
> If there is a compelling use case which justifies the resulting
> complexity, then it can be built on top. I'm not holding my breath. See
> above...
Perhaps the only thing that worries me is if an isolated partition
is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then
cpuset is overwritten so that the reverse is applied: 0-3 is isolated
and 4-7 is not isolated. If all isol works reach before unisol works,
then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask)
won't find any CPU left on the last call.
Now last time I tried to invert an isolated cpumask in cpuset, I got
-EINVAL so something must be preventing from that. Just in case let's
have a WARN_ON_ONCE(cpumask_any(tmigr_available_mask) >= nr_cpu_ids).
But other than this detail, your solution looks good!
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 22:02 ` Frederic Weisbecker
@ 2025-11-19 22:10 ` Thomas Gleixner
2025-11-19 22:31 ` Frederic Weisbecker
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Gleixner @ 2025-11-19 22:10 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
On Wed, Nov 19 2025 at 23:02, Frederic Weisbecker wrote:
> Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a écrit :
>> If you want to be a bit smarter, then you can just use a global mutex,
>> which is taken inside the set/clear_available() functions which
>> serializes the related functionality and bulk schedule/flush the unisol
>> (make available) first and then proceed to the isol (make unavailable).
>>
>> Then nothing has to change vs. the set/clear operations and everything
>> just works.
>>
>> That mutex does not do any harm in the CPU hotplug case and the
>> serialization vs. the workers is not going to be the end of the world.
>>
>> I'm willing to bet that no real-world use-case will ever notice the
>> existance of this mutex. The microbenchmark which shows off the "I'm so
>> smart" metric is completely irrelevant especially when the result is
>> fragile, incomprehensible and therefore unmaintainable.
>>
>> Keep it correct and simple is still the most important engineering
>> principle. Premature optimization is a guaranteed path to failure.
>>
>> If there is a compelling use case which justifies the resulting
>> complexity, then it can be built on top. I'm not holding my breath. See
>> above...
>
> Perhaps the only thing that worries me is if an isolated partition
> is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then
> cpuset is overwritten so that the reverse is applied: 0-3 is isolated
> and 4-7 is not isolated. If all isol works reach before unisol works,
> then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask)
> won't find any CPU left on the last call.
schedule the newly available (now unisolated) ones first and flush that
work. After that you can safely mark the others unavailable, no?
Thanks
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 22:10 ` Thomas Gleixner
@ 2025-11-19 22:31 ` Frederic Weisbecker
0 siblings, 0 replies; 24+ messages in thread
From: Frederic Weisbecker @ 2025-11-19 22:31 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen, Waiman Long,
John B. Wyatt IV, John B. Wyatt IV
Le Wed, Nov 19, 2025 at 11:10:58PM +0100, Thomas Gleixner a écrit :
> On Wed, Nov 19 2025 at 23:02, Frederic Weisbecker wrote:
> > Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a écrit :
> >> If you want to be a bit smarter, then you can just use a global mutex,
> >> which is taken inside the set/clear_available() functions which
> >> serializes the related functionality and bulk schedule/flush the unisol
> >> (make available) first and then proceed to the isol (make unavailable).
> >>
> >> Then nothing has to change vs. the set/clear operations and everything
> >> just works.
> >>
> >> That mutex does not do any harm in the CPU hotplug case and the
> >> serialization vs. the workers is not going to be the end of the world.
> >>
> >> I'm willing to bet that no real-world use-case will ever notice the
> >> existance of this mutex. The microbenchmark which shows off the "I'm so
> >> smart" metric is completely irrelevant especially when the result is
> >> fragile, incomprehensible and therefore unmaintainable.
> >>
> >> Keep it correct and simple is still the most important engineering
> >> principle. Premature optimization is a guaranteed path to failure.
> >>
> >> If there is a compelling use case which justifies the resulting
> >> complexity, then it can be built on top. I'm not holding my breath. See
> >> above...
> >
> > Perhaps the only thing that worries me is if an isolated partition
> > is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then
> > cpuset is overwritten so that the reverse is applied: 0-3 is isolated
> > and 4-7 is not isolated. If all isol works reach before unisol works,
> > then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask)
> > won't find any CPU left on the last call.
>
> schedule the newly available (now unisolated) ones first and flush that
> work. After that you can safely mark the others unavailable, no?
Yes!
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-13 8:33 ` [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-11-19 16:50 ` Thomas Gleixner
@ 2025-11-19 20:43 ` Waiman Long
2025-11-20 10:48 ` Gabriele Monaco
1 sibling, 1 reply; 24+ messages in thread
From: Waiman Long @ 2025-11-19 20:43 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Thomas Gleixner
Cc: John B. Wyatt IV, John B. Wyatt IV
On 11/13/25 3:33 AM, Gabriele Monaco wrote:
> The timer migration mechanism allows active CPUs to pull timers from
> idle ones to improve the overall idle time. This is however undesired
> when CPU intensive workloads run on isolated cores, as the algorithm
> would move the timers from housekeeping to isolated cores, negatively
> affecting the isolation.
>
> Exclude isolated cores from the timer migration algorithm, extend the
> concept of unavailable cores, currently used for offline ones, to
> isolated ones:
> * A core is unavailable if isolated or offline;
> * A core is available if non isolated and online;
>
> A core is considered unavailable as isolated if it belongs to:
> * the isolcpus (domain) list
> * an isolated cpuset
> Except if it is:
> * in the nohz_full list (already idle for the hierarchy)
> * the nohz timekeeper core (must be available to handle global timers)
>
> CPUs are added to the hierarchy during late boot, excluding isolated
> ones, the hierarchy is also adapted when the cpuset isolation changes.
>
> Due to how the timer migration algorithm works, any CPU part of the
> hierarchy can have their global timers pulled by remote CPUs and have to
> pull remote timers, only skipping pulling remote timers would break the
> logic.
> For this reason, prevent isolated CPUs from pulling remote global
> timers, but also the other way around: any global timer started on an
> isolated CPU will run there. This does not break the concept of
> isolation (global timers don't come from outside the CPU) and, if
> considered inappropriate, can usually be mitigated with other isolation
> techniques (e.g. IRQ pinning).
>
> This effect was noticed on a 128 cores machine running oslat on the
> isolated cores (1-31,33-63,65-95,97-127). The tool monopolises CPUs,
> and the CPU with lowest count in a timer migration hierarchy (here 1
> and 65) appears as always active and continuously pulls global timers,
> from the housekeeping CPUs. This ends up moving driver work (e.g.
> delayed work) to isolated CPUs and causes latency spikes:
>
> before the change:
>
> # oslat -c 1-31,33-63,65-95,97-127 -D 62s
> ...
> Maximum: 1203 10 3 4 ... 5 (us)
>
> after the change:
>
> # oslat -c 1-31,33-63,65-95,97-127 -D 62s
> ...
> Maximum: 10 4 3 4 3 ... 5 (us)
>
> The same behaviour was observed on a machine with as few as 20 cores /
> 40 threads with isocpus set to: 1-9,11-39 with rtla-osnoise-top.
>
> Tested-by: John B. Wyatt IV <jwyatt@redhat.com>
> Tested-by: John B. Wyatt IV <sageofredondo@gmail.com>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
> include/linux/timer.h | 9 ++
> kernel/cgroup/cpuset.c | 3 +
> kernel/time/timer_migration.c | 156 ++++++++++++++++++++++++++++++++--
> 3 files changed, 163 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/timer.h b/include/linux/timer.h
> index 0414d9e6b4fc..62e1cea71125 100644
> --- a/include/linux/timer.h
> +++ b/include/linux/timer.h
> @@ -188,4 +188,13 @@ int timers_dead_cpu(unsigned int cpu);
> #define timers_dead_cpu NULL
> #endif
>
> +#if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
> +extern int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask);
> +#else
> +static inline int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index cf34623fe66f..bfc3b319e1c0 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1350,6 +1350,9 @@ static void update_isolation_cpumasks(bool isolcpus_updated)
>
> ret = workqueue_unbound_exclude_cpumask(isolated_cpus);
> WARN_ON_ONCE(ret < 0);
> +
> + ret = tmigr_isolated_exclude_cpumask(isolated_cpus);
> + WARN_ON_ONCE(ret < 0);
> }
>
> /**
> diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
> index d3eb9714e692..0e275d526d50 100644
> --- a/kernel/time/timer_migration.c
> +++ b/kernel/time/timer_migration.c
> @@ -10,6 +10,7 @@
> #include <linux/spinlock.h>
> #include <linux/timerqueue.h>
> #include <trace/events/ipi.h>
> +#include <linux/sched/isolation.h>
>
> #include "timer_migration.h"
> #include "tick-internal.h"
> @@ -430,6 +431,9 @@ static DEFINE_PER_CPU(struct tmigr_cpu, tmigr_cpu);
> */
> static cpumask_var_t tmigr_available_cpumask;
>
> +/* Enabled during late initcall */
> +static DEFINE_STATIC_KEY_FALSE(tmigr_exclude_isolated);
> +
> #define TMIGR_NONE 0xFF
> #define BIT_CNT 8
>
> @@ -438,6 +442,33 @@ static inline bool tmigr_is_not_available(struct tmigr_cpu *tmc)
> return !(tmc->tmgroup && tmc->available);
> }
>
> +/*
> + * Returns true if @cpu should be excluded from the hierarchy as isolated.
> + * Domain isolated CPUs don't participate in timer migration, nohz_full CPUs
> + * are still part of the hierarchy but become idle (from a tick and timer
> + * migration perspective) when they stop their tick. This lets the timekeeping
> + * CPU handle their global timers. Marking also isolated CPUs as idle would be
> + * too costly, hence they are completely excluded from the hierarchy.
> + * This check is necessary, for instance, to prevent offline isolated CPUs from
> + * being incorrectly marked as available once getting back online.
> + *
> + * This function returns false during early boot and the isolation logic is
> + * enabled only after isolated CPUs are marked as unavailable at late boot.
> + * The tick CPU can be isolated at boot, however we cannot mark it as
> + * unavailable to avoid having no global migrator for the nohz_full CPUs. This
> + * should be ensured by the callers of this function: implicitly from hotplug
> + * callbacs and explicitly in tmigr_init_isolation and
> + * tmigr_isolated_exclude_cpumask.
> + */
> +static inline bool tmigr_is_isolated(int cpu)
> +{
> + if (static_branch_unlikely(&tmigr_exclude_isolated))
> + return (!housekeeping_cpu(cpu, HK_TYPE_DOMAIN) ||
> + cpuset_cpu_is_isolated(cpu)) &&
> + housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE);
> + return false;
> +}
> +
> /*
> * Returns true, when @childmask corresponds to the group migrator or when the
> * group is not active - so no migrator is set.
> @@ -1439,8 +1470,9 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
> int migrator;
> u64 firstexp;
>
> - cpumask_clear_cpu(cpu, tmigr_available_cpumask);
> scoped_guard(raw_spinlock_irq, &tmc->lock) {
> + if (!tmc->available)
> + return 0;
> tmc->available = false;
> WRITE_ONCE(tmc->wakeup, KTIME_MAX);
>
> @@ -1453,11 +1485,11 @@ static int tmigr_clear_cpu_available(unsigned int cpu)
> }
>
> if (firstexp != KTIME_MAX) {
> - migrator = cpumask_any(tmigr_available_cpumask);
> + migrator = cpumask_any_but(tmigr_available_cpumask, cpu);
> work_on_cpu(migrator, tmigr_trigger_active, NULL);
> }
>
> - return 0;
> + return 1;
> }
>
> static int tmigr_set_cpu_available(unsigned int cpu)
> @@ -1468,17 +1500,130 @@ static int tmigr_set_cpu_available(unsigned int cpu)
> if (WARN_ON_ONCE(!tmc->tmgroup))
> return -EINVAL;
>
> - cpumask_set_cpu(cpu, tmigr_available_cpumask);
> + if (tmigr_is_isolated(cpu))
> + return 0;
> +
> scoped_guard(raw_spinlock_irq, &tmc->lock) {
> + if (tmc->available)
> + return 0;
> trace_tmigr_cpu_available(tmc);
> tmc->idle = timer_base_is_idle();
> if (!tmc->idle)
> __tmigr_cpu_activate(tmc);
> tmc->available = true;
> }
> + return 1;
> +}
> +
> +static int tmigr_online_cpu(unsigned int cpu)
> +{
> + if (tmigr_set_cpu_available(cpu) > 0)
> + cpumask_set_cpu(cpu, tmigr_available_cpumask);
> + return 0;
> +}
> +
> +static int tmigr_offline_cpu(unsigned int cpu)
> +{
> + if (tmigr_clear_cpu_available(cpu) > 0)
> + cpumask_clear_cpu(cpu, tmigr_available_cpumask);
> + return 0;
> +}
> +
> +static void tmigr_cpu_isolate(struct work_struct *ignored)
> +{
> + tmigr_clear_cpu_available(smp_processor_id());
> +}
> +
> +static void tmigr_cpu_unisolate(struct work_struct *ignored)
> +{
> + tmigr_set_cpu_available(smp_processor_id());
> +}
> +
> +static int __tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> +{
> + struct work_struct __percpu *works __free(free_percpu) =
> + alloc_percpu(struct work_struct);
> + cpumask_var_t cpumask_unisol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> + cpumask_var_t cpumask_isol __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> + int cpu;
There are currently only 2 callers for this function - from late_init
call and from cpuset. Concurrent call is not possible. Maybe we can just
pre-allocate these cpumask_var_t and percpu work structures once and
reuse it instead of doing an allocation and free each time it is called.
The pre-allocation can be done in tmigr_init_isolation().
> +
> + if (!alloc_cpumask_var(&cpumask_isol, GFP_KERNEL))
> + return -ENOMEM;
> + if (!alloc_cpumask_var(&cpumask_unisol, GFP_KERNEL))
> + return -ENOMEM;
> + if (!works)
> + return -ENOMEM;
> +
> + cpumask_andnot(cpumask_unisol, cpu_online_mask, exclude_cpumask);
> + cpumask_andnot(cpumask_unisol, cpumask_unisol, tmigr_available_cpumask);
> + /* Set up the mask earlier to avoid races with the migrator CPU */
> + cpumask_or(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_unisol);
> + for_each_cpu(cpu, cpumask_unisol) {
> + struct work_struct *work = per_cpu_ptr(works, cpu);
> +
> + INIT_WORK(work, tmigr_cpu_unisolate);
> + schedule_work_on(cpu, work);
> + }
> +
> + cpumask_and(cpumask_isol, exclude_cpumask, tmigr_available_cpumask);
> + cpumask_and(cpumask_isol, cpumask_isol, housekeeping_cpumask(HK_TYPE_KERNEL_NOISE));
> + /*
> + * Handle this here and not in the cpuset code because exclude_cpumask
> + * might include also the tick CPU if included in isolcpus.
> + */
> + for_each_cpu(cpu, cpumask_isol) {
> + if (!tick_nohz_cpu_hotpluggable(cpu)) {
> + cpumask_clear_cpu(cpu, cpumask_isol);
> + break;
> + }
> + }
> + /* Set up the mask earlier to avoid races with the migrator CPU */
> + cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol);
> + for_each_cpu(cpu, cpumask_isol) {
> + struct work_struct *work = per_cpu_ptr(works, cpu);
> +
> + INIT_WORK(work, tmigr_cpu_isolate);
> + schedule_work_on(cpu, work);
> + }
> +
> + for_each_cpu_or(cpu, cpumask_isol, cpumask_unisol)
> + flush_work(per_cpu_ptr(works, cpu));
> +
> return 0;
> }
>
> +/**
> + * tmigr_isolated_exclude_cpumask - Exclude given CPUs from hierarchy
> + * @exclude_cpumask: the cpumask to be excluded from timer migration hierarchy
> + *
> + * This function can be called from cpuset code to provide the new set of
> + * isolated CPUs that should be excluded from the hierarchy.
> + * Online CPUs not present in exclude_cpumask but already excluded are brought
> + * back to the hierarchy.
> + * Functions to isolate/unisolate need to be called locally and can sleep.
> + */
> +int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> +{
> + lockdep_assert_cpus_held();
> + return __tmigr_isolated_exclude_cpumask(exclude_cpumask);
> +}
> +
> +static int __init tmigr_init_isolation(void)
> +{
> + cpumask_var_t cpumask __free(free_cpumask_var) = CPUMASK_VAR_NULL;
> +
> + static_branch_enable(&tmigr_exclude_isolated);
> +
> + if (!housekeeping_enabled(HK_TYPE_DOMAIN))
> + return 0;
> + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + cpumask_andnot(cpumask, cpu_possible_mask, housekeeping_cpumask(HK_TYPE_DOMAIN));
> +
> + return __tmigr_isolated_exclude_cpumask(cpumask);
> +}
Should we put all these functions under "#if defined(CONFIG_SMP) &&
defined(CONFIG_NO_HZ_COMMON)" like in the timer.h header file?
Cheers,
Longman
> +
> static void tmigr_init_group(struct tmigr_group *group, unsigned int lvl,
> int node)
> {
> @@ -1867,7 +2012,7 @@ static int __init tmigr_init(void)
> goto err;
>
> ret = cpuhp_setup_state(CPUHP_AP_TMIGR_ONLINE, "tmigr:online",
> - tmigr_set_cpu_available, tmigr_clear_cpu_available);
> + tmigr_online_cpu, tmigr_offline_cpu);
> if (ret)
> goto err;
>
> @@ -1878,3 +2023,4 @@ static int __init tmigr_init(void)
> return ret;
> }
> early_initcall(tmigr_init);
> +late_initcall(tmigr_init_isolation);
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-19 20:43 ` Waiman Long
@ 2025-11-20 10:48 ` Gabriele Monaco
2025-11-20 21:04 ` Waiman Long
0 siblings, 1 reply; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-20 10:48 UTC (permalink / raw)
To: Waiman Long, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Thomas Gleixner
Cc: John B. Wyatt IV, John B. Wyatt IV
On Wed, 2025-11-19 at 15:43 -0500, Waiman Long wrote:
> On 11/13/25 3:33 AM, Gabriele Monaco wrote:
> >
> > +static int __tmigr_isolated_exclude_cpumask(struct cpumask
> > *exclude_cpumask)
> > +{
> > + struct work_struct __percpu *works __free(free_percpu) =
> > + alloc_percpu(struct work_struct);
> > + cpumask_var_t cpumask_unisol __free(free_cpumask_var) =
> > CPUMASK_VAR_NULL;
> > + cpumask_var_t cpumask_isol __free(free_cpumask_var) =
> > CPUMASK_VAR_NULL;
> > + int cpu;
>
> There are currently only 2 callers for this function - from late_init
> call and from cpuset. Concurrent call is not possible. Maybe we can just
> pre-allocate these cpumask_var_t and percpu work structures once and
> reuse it instead of doing an allocation and free each time it is called.
> The pre-allocation can be done in tmigr_init_isolation().
>
I have no strong opinion on this, but after changes suggested by Thomas it gets
superfluous to allocate 2 cpumasks (after flushing what is now cpumask_unisol
it's no longer needed and we can re-use it).
Considering this only runs at boot and every time a cpuset changes isolation, is
it worth the extra steps to pre-allocate?
> >
> > +/**
> > + * tmigr_isolated_exclude_cpumask - Exclude given CPUs from hierarchy
> > + * @exclude_cpumask: the cpumask to be excluded from timer migration
> > hierarchy
> > + *
> > + * This function can be called from cpuset code to provide the new set of
> > + * isolated CPUs that should be excluded from the hierarchy.
> > + * Online CPUs not present in exclude_cpumask but already excluded are
> > brought
> > + * back to the hierarchy.
> > + * Functions to isolate/unisolate need to be called locally and can sleep.
> > + */
> > +int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
> > +{
> > + lockdep_assert_cpus_held();
> > + return __tmigr_isolated_exclude_cpumask(exclude_cpumask);
> > +}
> >
>
> Should we put all these functions under "#if defined(CONFIG_SMP) &&
> defined(CONFIG_NO_HZ_COMMON)" like in the timer.h header file?
I think that's implied in the build condition of timer_migration.o
https://elixir.bootlin.com/linux/v6.17.8/source/kernel/time/Makefile#L27
At least I got these ifdefs from timer_migration.h and none of those functions
are ifdeffed in timer_migration.c
Thanks,
Gabriele
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration
2025-11-20 10:48 ` Gabriele Monaco
@ 2025-11-20 21:04 ` Waiman Long
0 siblings, 0 replies; 24+ messages in thread
From: Waiman Long @ 2025-11-20 21:04 UTC (permalink / raw)
To: Gabriele Monaco, Waiman Long, linux-kernel, Anna-Maria Behnsen,
Frederic Weisbecker, Thomas Gleixner
Cc: John B. Wyatt IV, John B. Wyatt IV
On 11/20/25 5:48 AM, Gabriele Monaco wrote:
> On Wed, 2025-11-19 at 15:43 -0500, Waiman Long wrote:
>> On 11/13/25 3:33 AM, Gabriele Monaco wrote:
>>> +static int __tmigr_isolated_exclude_cpumask(struct cpumask
>>> *exclude_cpumask)
>>> +{
>>> + struct work_struct __percpu *works __free(free_percpu) =
>>> + alloc_percpu(struct work_struct);
>>> + cpumask_var_t cpumask_unisol __free(free_cpumask_var) =
>>> CPUMASK_VAR_NULL;
>>> + cpumask_var_t cpumask_isol __free(free_cpumask_var) =
>>> CPUMASK_VAR_NULL;
>>> + int cpu;
>> There are currently only 2 callers for this function - from late_init
>> call and from cpuset. Concurrent call is not possible. Maybe we can just
>> pre-allocate these cpumask_var_t and percpu work structures once and
>> reuse it instead of doing an allocation and free each time it is called.
>> The pre-allocation can be done in tmigr_init_isolation().
>>
> I have no strong opinion on this, but after changes suggested by Thomas it gets
> superfluous to allocate 2 cpumasks (after flushing what is now cpumask_unisol
> it's no longer needed and we can re-use it).
>
> Considering this only runs at boot and every time a cpuset changes isolation, is
> it worth the extra steps to pre-allocate?
It is just a suggestion. We can see how it goes and decide if this
change is needed or not.
>
>>>
>>> +/**
>>> + * tmigr_isolated_exclude_cpumask - Exclude given CPUs from hierarchy
>>> + * @exclude_cpumask: the cpumask to be excluded from timer migration
>>> hierarchy
>>> + *
>>> + * This function can be called from cpuset code to provide the new set of
>>> + * isolated CPUs that should be excluded from the hierarchy.
>>> + * Online CPUs not present in exclude_cpumask but already excluded are
>>> brought
>>> + * back to the hierarchy.
>>> + * Functions to isolate/unisolate need to be called locally and can sleep.
>>> + */
>>> +int tmigr_isolated_exclude_cpumask(struct cpumask *exclude_cpumask)
>>> +{
>>> + lockdep_assert_cpus_held();
>>> + return __tmigr_isolated_exclude_cpumask(exclude_cpumask);
>>> +}
>>>
>> Should we put all these functions under "#if defined(CONFIG_SMP) &&
>> defined(CONFIG_NO_HZ_COMMON)" like in the timer.h header file?
> I think that's implied in the build condition of timer_migration.o
> https://elixir.bootlin.com/linux/v6.17.8/source/kernel/time/Makefile#L27
>
> At least I got these ifdefs from timer_migration.h and none of those functions
> are ifdeffed in timer_migration.c
You are right. I haven't check the condition for building timer_migration.o.
Cheers,
Longman
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration
2025-11-13 8:33 [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
` (6 preceding siblings ...)
2025-11-13 8:33 ` [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration Gabriele Monaco
@ 2025-11-13 13:12 ` Frederic Weisbecker
2025-11-18 10:01 ` Gabriele Monaco
7 siblings, 1 reply; 24+ messages in thread
From: Frederic Weisbecker @ 2025-11-13 13:12 UTC (permalink / raw)
To: Gabriele Monaco
Cc: linux-kernel, Anna-Maria Behnsen, Thomas Gleixner, Waiman Long
Le Thu, Nov 13, 2025 at 09:33:17AM +0100, Gabriele Monaco a écrit :
> The timer migration mechanism allows active CPUs to pull timers from
> idle ones to improve the overall idle time. This is however undesired
> when CPU intensive workloads run on isolated cores, as the algorithm
> would move the timers from housekeeping to isolated cores, negatively
> affecting the isolation.
>
> Exclude isolated cores from the timer migration algorithm, extend the
> concept of unavailable cores, currently used for offline ones, to
> isolated ones:
> * A core is unavailable if isolated or offline;
> * A core is available if non isolated and online;
>
> A core is considered unavailable as isolated if it belongs to:
> * the isolcpus (domain) list
> * an isolated cpuset
> Except if it is:
> * in the nohz_full list (already idle for the hierarchy)
> * the nohz timekeeper core (must be available to handle global timers)
>
> CPUs are added to the hierarchy during late boot, excluding isolated
> ones, the hierarchy is also adapted when the cpuset isolation changes.
>
> Due to how the timer migration algorithm works, any CPU part of the
> hierarchy can have their global timers pulled by remote CPUs and have to
> pull remote timers, only skipping pulling remote timers would break the
> logic.
> For this reason, prevent isolated CPUs from pulling remote global
> timers, but also the other way around: any global timer started on an
> isolated CPU will run there. This does not break the concept of
> isolation (global timers don't come from outside the CPU) and, if
> considered inappropriate, can usually be mitigated with other isolation
> techniques (e.g. IRQ pinning).
>
> This effect was noticed on a 128 cores machine running oslat on the
> isolated cores (1-31,33-63,65-95,97-127). The tool monopolises CPUs,
> and the CPU with lowest count in a timer migration hierarchy (here 1
> and 65) appears as always active and continuously pulls global timers,
> from the housekeeping CPUs. This ends up moving driver work (e.g.
> delayed work) to isolated CPUs and causes latency spikes:
>
> before the change:
>
> # oslat -c 1-31,33-63,65-95,97-127 -D 62s
> ...
> Maximum: 1203 10 3 4 ... 5 (us)
>
> after the change:
>
> # oslat -c 1-31,33-63,65-95,97-127 -D 62s
> ...
> Maximum: 10 4 3 4 3 ... 5 (us)
>
> The same behaviour was observed on a machine with as few as 20 cores /
> 40 threads with isocpus set to: 1-9,11-39 with rtla-osnoise-top.
>
> The first 4 patches are preparatory work to change the concept of
> online/offline to available/unavailable, keep track of those in a
> separate cpumask cleanup the setting/clearing functions and change a
> function name in cpuset code.
>
> Patch 5 adapt isolation to prevent domain isolated and nohz_full from
> covering all CPUs not leaving any housekeeping one. This can lead to
> problems with the changes introduced in this series because no CPU would
> remain to handle global timers.
> (The corresponding change for cpuset was removed from this version of
> the series and is present in [2]).
>
> Patch 7 extends the unavailable status to domain isolated CPUs, which
> is the main contribution of the series.
>
> Changes since v14:
> * Rebase on tip/timers/core, rename one more ->online field
> * Mark the static key as static
> * Share code between tmigr_init_isolation and tmigr_isolated_exclude_cpumask
>
> Changes since v13:
> * Remove tmigr late initialisation and restore late isolation (as in v8 [1])
> * Use workqueues in initialisation just like tmigr_available_cpumask()
> * Use static key for tmigr_exclude_isolated
> * Remove cpuset patch checking for HK conflict (included in [2])
> * Rename cpuset helper to update_isolation_cpumasks as in [2]
>
> Changes since v12:
> * Pick and adapt patch by Yury Norov to initialise cpumasks
> * Reorganise accesses to tmigr_available_cpumask to avoid races
>
> Changes since v11:
> * Rename isolcpus_nohz_conflict() to isolated_cpus_can_update()
> * Move tick_nohz_cpu_hotpluggable() check to tmigr_is_isolated()
> * Use workqueues in tmigr_isolated_exclude_cpumask() to avoid sleeping
> while atomic
> * Add cpumask initialiser to safely use cpumask cleanup helpers
>
> Changes since v10:
> * Simplify housekeeping conflict condition
> * Reword commit (Frederic Weisbecker)
>
> Changes since v9:
> * Fix total housekeeping enforcement to focus only on nohz and domain
> * Avoid out of bound access in the housekeeping array if no flag is set
> * Consider isolated_cpus while checking for nohz conflicts in cpuset
> * Improve comment about why nohz CPUs are not excluded by tmigr
>
> Changes since v8 [1]:
> * Postpone hotplug registration to late initcall (Frederic Weisbecker)
> * Move main activation logic in _tmigr_set_cpu_available() and call it
> after checking for isolation on hotplug and cpusets changes
> * Call _tmigr_set_cpu_available directly to force enable tick CPU if
> required (this saves checking for that on every hotplug change).
>
> Changes since v7:
> * Move tmigr_available_cpumask out of tmc lock and specify conditions.
> * Initialise tmigr isolation despite the state of isolcpus.
> * Move tick CPU check to condition to run SMP call.
> * Fix descriptions.
>
> Changes since v6 [3]:
> * Prevent isolation checks from running during early boot
> * Prevent double (de)activation while setting cpus (un)available
> * Use synchronous smp calls from the isolation path
> * General cleanup
>
> Changes since v5:
> * Remove fallback if no housekeeping is left by isolcpus and nohz_full
> * Adjust condition not to activate CPUs in the migration hierarchy
> * Always force the nohz tick CPU active in the hierarchy
>
> Changes since v4 [4]:
> * use on_each_cpu_mask() with changes on isolated CPUs to avoid races
> * keep nohz_full CPUs included in the timer migration hierarchy
> * prevent domain isolated and nohz_full to cover all CPUs
>
> Changes since v3:
> * add parameter to function documentation
> * split into multiple straightforward patches
>
> Changes since v2:
> * improve comments about handling CPUs isolated at boot
> * minor cleanup
>
> Changes since v1 [5]:
> * split into smaller patches
> * use available mask instead of unavailable
> * simplification and cleanup
>
> [1] - https://lore.kernel.org/lkml/20250714133050.193108-9-gmonaco@redhat.com
> [2] - https://lore.kernel.org/lkml/20251104013037.296013-1-longman@redhat.com
> [3] - https://lore.kernel.org/lkml/20250530142031.215594-1-gmonaco@redhat.com
> [4] - https://lore.kernel.org/lkml/20250506091534.42117-7-gmonaco@redhat.com
> [5] - https://lore.kernel.org/lkml/20250410065446.57304-2-gmonaco@redhat.com
>
> Gabriele Monaco (6):
> timers: Rename tmigr 'online' bit to 'available'
> timers: Add the available mask in timer migration
> timers: Use scoped_guard when setting/clearing the tmigr available
> flag
> cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to
> update_isolation_cpumasks()
> sched/isolation: Force housekeeping if isolcpus and nohz_full don't
> leave any
> timers: Exclude isolated cpus from timer migration
>
> Yury Norov (1):
> cpumask: Add initialiser to use cleanup helpers
>
> include/linux/cpumask.h | 2 +
> include/linux/timer.h | 9 ++
> include/trace/events/timer_migration.h | 4 +-
> kernel/cgroup/cpuset.c | 15 +-
> kernel/sched/isolation.c | 23 +++
> kernel/time/timer_migration.c | 213 +++++++++++++++++++++----
> kernel/time/timer_migration.h | 2 +-
> 7 files changed, 232 insertions(+), 36 deletions(-)
>
>
> base-commit: ba14500e4bfcab5e841fbf8d7fcbbc80e98d6b9e
Looks good to me now, thanks!
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v15 0/7] timers: Exclude isolated cpus from timer migration
2025-11-13 13:12 ` [PATCH v15 0/7] " Frederic Weisbecker
@ 2025-11-18 10:01 ` Gabriele Monaco
0 siblings, 0 replies; 24+ messages in thread
From: Gabriele Monaco @ 2025-11-18 10:01 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, Anna-Maria Behnsen, Thomas Gleixner, Waiman Long
On Thu, 2025-11-13 at 14:12 +0100, Frederic Weisbecker wrote:
> Le Thu, Nov 13, 2025 at 09:33:17AM +0100, Gabriele Monaco a écrit :
> > The timer migration mechanism allows active CPUs to pull timers from
> > idle ones to improve the overall idle time. This is however undesired
> > when CPU intensive workloads run on isolated cores, as the algorithm
> > would move the timers from housekeeping to isolated cores, negatively
> > affecting the isolation.
>
> Looks good to me now, thanks!
Thank you for all the comments! Will this series make it for this merge window?
Thanks,
Gabriele
^ permalink raw reply [flat|nested] 24+ messages in thread