[PATCH] tracing: sched: Hide numa events under CONFIG_NUMA_BALANCING

Steven Rostedt posted 1 patch 4 months ago
include/trace/events/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] tracing: sched: Hide numa events under CONFIG_NUMA_BALANCING
Posted by Steven Rostedt 4 months ago
From: Steven Rostedt <rostedt@goodmis.org>

The events sched_move_numa, sched_stick_numa and sched_swap_numa are only
called when CONFIG_NUMA_BALANCING is configured. As each event can take up
to 5K of memory in text and meta data regardless if they are used or not,
they should not be defined when used.

Move the #ifdef CONFIG_NUMA_BALANCING to hide these events as well.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
Note, I will be adding code soon that will make unused events cause a warning.

 include/trace/events/sched.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 4e6b2910cec3..0243f32e068a 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -628,6 +628,7 @@ TRACE_EVENT(sched_process_hang,
 );
 #endif /* CONFIG_DETECT_HUNG_TASK */
 
+#ifdef CONFIG_NUMA_BALANCING
 /*
  * Tracks migration of tasks from one runqueue to another. Can be used to
  * detect if automatic NUMA balancing is bouncing between nodes.
@@ -720,7 +721,6 @@ DEFINE_EVENT(sched_numa_pair_template, sched_swap_numa,
 	TP_ARGS(src_tsk, src_cpu, dst_tsk, dst_cpu)
 );
 
-#ifdef CONFIG_NUMA_BALANCING
 #define NUMAB_SKIP_REASON					\
 	EM( NUMAB_SKIP_UNSUITABLE,		"unsuitable" )	\
 	EM( NUMAB_SKIP_SHARED_RO,		"shared_ro" )	\
-- 
2.47.2
Re: [PATCH] tracing: sched: Hide numa events under CONFIG_NUMA_BALANCING
Posted by Shrikanth Hegde 2 months, 2 weeks ago

On 6/12/25 19:35, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> 
> The events sched_move_numa, sched_stick_numa and sched_swap_numa are only
> called when CONFIG_NUMA_BALANCING is configured. As each event can take up
> to 5K of memory in text and meta data regardless if they are used or not,
> they should not be defined when used.

they should be defined when used?

> 
> Move the #ifdef CONFIG_NUMA_BALANCING to hide these events as well.
> 
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> ---
> Note, I will be adding code soon that will make unused events cause a warning.
> 
>   include/trace/events/sched.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index 4e6b2910cec3..0243f32e068a 100644
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -628,6 +628,7 @@ TRACE_EVENT(sched_process_hang,
>   );
>   #endif /* CONFIG_DETECT_HUNG_TASK */
>   
> +#ifdef CONFIG_NUMA_BALANCING
>   /*
>    * Tracks migration of tasks from one runqueue to another. Can be used to
>    * detect if automatic NUMA balancing is bouncing between nodes.
> @@ -720,7 +721,6 @@ DEFINE_EVENT(sched_numa_pair_template, sched_swap_numa,
>   	TP_ARGS(src_tsk, src_cpu, dst_tsk, dst_cpu)
>   );
>   
> -#ifdef CONFIG_NUMA_BALANCING
>   #define NUMAB_SKIP_REASON					\
>   	EM( NUMAB_SKIP_UNSUITABLE,		"unsuitable" )	\
>   	EM( NUMAB_SKIP_SHARED_RO,		"shared_ro" )	\


Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Re: [PATCH] tracing: sched: Hide numa events under CONFIG_NUMA_BALANCING
Posted by Steven Rostedt 2 months, 2 weeks ago
On Wed, 23 Jul 2025 15:14:26 +0530
Shrikanth Hegde <sshegde@linux.ibm.com> wrote:

> On 6/12/25 19:35, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@goodmis.org>
> > 
> > The events sched_move_numa, sched_stick_numa and sched_swap_numa are only
> > called when CONFIG_NUMA_BALANCING is configured. As each event can take up
> > to 5K of memory in text and meta data regardless if they are used or not,
> > they should not be defined when used.  
> 
> they should be defined when used?

That was supposed to be: "they should not be defined when unused."

Thanks for pointing it out.

> 
> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>

Thanks!

-- Steve