[PATCH] xdp: Remove unused mem_return_failed event

[PATCH] xdp: Remove unused mem_return_failed event

[Steven Rostedt]

From: Steven Rostedt <rostedt@goodmis.org>

The change to allow page_poll to handle its own page destruction instead
of relying on XDP removed the trace_mem_return_failed() tracepoint caller,
but did not remove the mem_return_failed trace event. As trace events take
up memory when they are created regardless of if they are used or not,
having this unused event around wastes around 5K of memory.

Remove the unused event.

Link: https://lore.kernel.org/all/20250529130138.544ffec4@gandalf.local.home/

Fixes: c3f812cea0d7 ("page_pool: do not release pool until inflight == 0.")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 include/trace/events/xdp.h | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index a7e5452b5d21..d3ef86c97ae3 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -379,32 +379,6 @@ TRACE_EVENT(mem_connect,
 	)
 );
 
-TRACE_EVENT(mem_return_failed,
-
-	TP_PROTO(const struct xdp_mem_info *mem,
-		 const struct page *page),
-
-	TP_ARGS(mem, page),
-
-	TP_STRUCT__entry(
-		__field(const struct page *,	page)
-		__field(u32,		mem_id)
-		__field(u32,		mem_type)
-	),
-
-	TP_fast_assign(
-		__entry->page		= page;
-		__entry->mem_id		= mem->id;
-		__entry->mem_type	= mem->type;
-	),
-
-	TP_printk("mem_id=%d mem_type=%s page=%p",
-		  __entry->mem_id,
-		  __print_symbolic(__entry->mem_type, __MEM_TYPE_SYM_TAB),
-		  __entry->page
-	)
-);
-
 TRACE_EVENT(bpf_xdp_link_attach_failed,
 
 	TP_PROTO(const char *msg),
-- 
2.47.2

Re: [PATCH] xdp: Remove unused mem_return_failed event

[Jesper Dangaard Brouer]

On 29/05/2025 22.05, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> 
> The change to allow page_poll to handle its own page destruction instead
                            ^^^^
You miss-spelled page_pool as "page_poll"

> of relying on XDP removed the trace_mem_return_failed() tracepoint caller,
> but did not remove the mem_return_failed trace event. As trace events take
> up memory when they are created regardless of if they are used or not,
> having this unused event around wastes around 5K of memory.
> 
> Remove the unused event.
> 
> Link: https://lore.kernel.org/all/20250529130138.544ffec4@gandalf.local.home/
> 
> Fixes: c3f812cea0d7 ("page_pool: do not release pool until inflight == 0.")
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> ---
>   include/trace/events/xdp.h | 26 --------------------------
>   1 file changed, 26 deletions(-)

With above spelling fixed:

Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>


> diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
> index a7e5452b5d21..d3ef86c97ae3 100644
> --- a/include/trace/events/xdp.h
> +++ b/include/trace/events/xdp.h
> @@ -379,32 +379,6 @@ TRACE_EVENT(mem_connect,
>   	)
>   );
>   
> -TRACE_EVENT(mem_return_failed,
> -
> -	TP_PROTO(const struct xdp_mem_info *mem,
> -		 const struct page *page),
> -
> -	TP_ARGS(mem, page),
> -
> -	TP_STRUCT__entry(
> -		__field(const struct page *,	page)
> -		__field(u32,		mem_id)
> -		__field(u32,		mem_type)
> -	),
> -
> -	TP_fast_assign(
> -		__entry->page		= page;
> -		__entry->mem_id		= mem->id;
> -		__entry->mem_type	= mem->type;
> -	),
> -
> -	TP_printk("mem_id=%d mem_type=%s page=%p",
> -		  __entry->mem_id,
> -		  __print_symbolic(__entry->mem_type, __MEM_TYPE_SYM_TAB),
> -		  __entry->page
> -	)
> -);
> -
>   TRACE_EVENT(bpf_xdp_link_attach_failed,
>   
>   	TP_PROTO(const char *msg),

Re: [PATCH] xdp: Remove unused mem_return_failed event

[Steven Rostedt]

On Fri, 30 May 2025 08:51:12 +0200
Jesper Dangaard Brouer <hawk@kernel.org> wrote:

> > The change to allow page_poll to handle its own page destruction instead  
>                             ^^^^
> You miss-spelled page_pool as "page_poll"

Oops!

> 
> > of relying on XDP removed the trace_mem_return_failed() tracepoint caller,
> > but did not remove the mem_return_failed trace event. As trace events take
> > up memory when they are created regardless of if they are used or not,
> > having this unused event around wastes around 5K of memory.
> > 
> > Remove the unused event.
> > 
> > Link: https://lore.kernel.org/all/20250529130138.544ffec4@gandalf.local.home/
> > 
> > Fixes: c3f812cea0d7 ("page_pool: do not release pool until inflight == 0.")
> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> > ---
> >   include/trace/events/xdp.h | 26 --------------------------
> >   1 file changed, 26 deletions(-)  
> 
> With above spelling fixed:
> 
> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>

Thanks. Will this go through the networking tree or should I just take it?

-- Steve

Re: [PATCH] xdp: Remove unused mem_return_failed event

[Jakub Kicinski]

On Fri, 30 May 2025 12:16:38 -0400 Steven Rostedt wrote:
> > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>  
> 
> Thanks. Will this go through the networking tree or should I just take it?

If you're planning to send it to Linus in this MW, still, go for it:
Acked-by: Jakub Kicinski <kuba@kernel.org>
If you mean to keep it in your -next tree for next MW I think we should
take it to avoid conflict noise. But our -next tree is closed during MW
per linux-next preferences.

IOW please take it if you wanna ship it now, otherwise please repost
after MW?

Re: [PATCH] xdp: Remove unused mem_return_failed event

[Steven Rostedt]

On Fri, 30 May 2025 18:18:13 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Fri, 30 May 2025 12:16:38 -0400 Steven Rostedt wrote:
> > > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>    
> > 
> > Thanks. Will this go through the networking tree or should I just take it?  
> 
> If you're planning to send it to Linus in this MW, still, go for it:
> Acked-by: Jakub Kicinski <kuba@kernel.org>
> If you mean to keep it in your -next tree for next MW I think we should
> take it to avoid conflict noise. But our -next tree is closed during MW
> per linux-next preferences.
> 
> IOW please take it if you wanna ship it now, otherwise please repost
> after MW?

Yeah, I think I'll try to get it in now. I'll ping the maintainers of my
other patches to see if I can get them all in in one go.

Thanks,

-- Steve