Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display

On Tue, Dec 23, 2025 at 01:34:52PM -0500, Steven Rostedt wrote:

On Mon, 22 Dec 2025 22:56:22 -0500
Aaron Tomlin [off-list ref] wrote:

quoted

Add support for displaying bitmasks in human-readable list format (e.g.,
0,2-5,7) in addition to the default hexadecimal bitmap representation.
This is particularly useful when tracing CPU masks and other large
bitmasks where individual bit positions are more meaningful than their
hexadecimal encoding.

When the "bitmask-list" option is enabled, the printk "%*pbl" format
specifier is used to render bitmasks as comma-separated ranges, making
trace output easier to interpret for complex CPU configurations and
large bitmask values.

Hmm, I have a couple of issues with this change. One, this is global. It
affects all instances. The other is that if this is going to be done, then
instead of adding a parameter to trace_seq_bitmask(), another trace_seq_*
API should be created. Perhaps trace_seq_bitmask_cnt()? And have
trace_print_bitmask_seq() call them separately.

I'm still not convinced that this is needed. What examples do you see?
Should it be only for CPU bitmasks?

I think a bit more thought needs to be made on a change like this. There's
other options that were added that I now regret. I don't want to add
another one I wish we didn't have.

Hi Steve,

Thank you for the feedback.

Regarding the scope, I take your point that a global flag is perhaps too
blunt an instrument. I can see how making this instance-aware would be
preferable. I can look into refactoring this to ensure we pull the flags
from the specific trace_array associated with the current buffer instance
rather than the global state.

I agree with your suggestion to avoid polluting the existing
trace_seq_bitmask() signature. This would allow trace_print_bitmask_seq()
to branch between the two formats cleanly, as you suggested

As for the use case, I find this particularly invaluable when debugging IPI
latency or affinity issues on high-core-count systems. I typically run this
with the "nop" tracer enabled, focusing specifically on the
events/ipi/ipi_send_cpumask/ event.

When dealing with 128+ logical cores, interpreting a raw hexadecimal bitmap
to identify targeted CPUs is mentally taxing and prone to error. For
example, if I am investigating why CPU 6 is being interrupted, I might use
a filter such as "cpumask & CPU{6}". Seeing the resulting output as a range
list (e.g., 0-7) rather than a hexadecimal bitmask allows one to deduce
almost instantly which cluster of CPUs is involved in the IPI broadcast.



Kind regards,
-- 
Aaron Tomlin