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. 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
