There isn't any need for this irq_work to be run locally, so avoid doing
so when the CPU is isolated.
Note that this is especially bad as queueing it into a local isolated
CPU might add noise to what was meant to be traced in the first place.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
Changes since v1:
- Rebase to cater for:
04d4e665a609 ("sched/isolation: Use single feature type while
referring to housekeeping cpumask")
kernel/trace/trace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index bb2caf6aac01..250603b4eb3e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -12,6 +12,7 @@
* Copyright (C) 2004-2006 Ingo Molnar
* Copyright (C) 2004 Nadia Yvette Chambers
*/
+#include <linux/sched/isolation.h>
#include <linux/ring_buffer.h>
#include <generated/utsrelease.h>
#include <linux/stacktrace.h>
@@ -1726,7 +1727,7 @@ void latency_fsnotify(struct trace_array *tr)
* possible that we are called from __schedule() or do_idle(), which
* could cause a deadlock.
*/
- irq_work_queue(&tr->fsnotify_irqwork);
+ irq_work_queue_on(&tr->fsnotify_irqwork, housekeeping_any_cpu(HK_TYPE_MISC));
}
#elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
--
2.35.1
On 3/1/22 12:30, Nicolas Saenz Julienne wrote:
> There isn't any need for this irq_work to be run locally, so avoid doing
> so when the CPU is isolated.
>
> Note that this is especially bad as queueing it into a local isolated
> CPU might add noise to what was meant to be traced in the first place.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Reviewed-by: Daniel Bristot de Oliveira <[email protected]>
-- Daniel