On 2025/6/13 20:17, Steven Rostedt wrote:
On Fri, 13 Jun 2025 14:08:32 +0800
Gao Xiang <hsiang...@linux.alibaba.com> wrote:

Hi Steven,

On 2025/6/13 10:49, Steven Rostedt wrote:
I have code that will trigger a warning if a trace event is defined but
not used[1]. It gives a list of unused events. Here's what I have for
erofs:

warning: tracepoint 'erofs_destroy_inode' is unused.

I'm fine to remove it, also I wonder if it's possible to disable
erofs tracepoints (rather than disable all tracepoints) in some
embedded use cases because erofs tracepoints might not be useful for
them and it can save memory (and .ko size) as you said below.

You can add #ifdef around them.

Should we introduce a new CONFIG to disable them?

Thanks,
Hongbo

Note, the "up to around 5K" means it can add up to that much depending on
what you have configured. The TRACE_EVENT() macro (and more specifically
the DECLARE_EVENT_CLASS() which TRACE_EVENT() has), is where all the bloat
is. I generates unique code for each trace event that prints it, parses it,
records it, the event fields, and has code specific for perf, ftrace and BPF.

The DEFINE_EVENT() which can be used to make several events that are
similar use the same DECLARE_EVENT_CLASS() only takes up around 250 bytes.
One reason I tell people to use DECLARE_EVENT_CLASS() when you have similar 
events.

There's also a DEFINE_EVENT_PRINT() that can use an existing
DECLARE_EVENT_CLASS() but update the "printk" section. That adds some more
code (the creation of the print function) but still much smaller than the
DECLARE_EVENT_CLASS(). But this requires the tracepoint function (what the
code calls) must have the same prototype.



Each trace event can take up to around 5K in memory regardless if they
are used or not. Soon there will be warnings when they are defined but
not used. Please remove any unused trace event or at least hide it
under an #ifdef if they are used within configs. I'm planning on adding
these warning in the next merge window.

If you don't have some interest to submit a removal patch, I will post
a patch later.

Please make the patch. There's too many for me to do them all.

Thanks!

-- Steve


Reply via email to