On Mon, 29 Dec 2025 13:29:42 -0500
Steven Rostedt <[email protected]> wrote:
> I just don't like wasting valuable ring buffer space for something that can
> be easily determined without it.
>
> How about this. I just wrote up this patch, and it could be something you
> use. I tested it against the sched waking events, by adding:
>
> __entry->target_cpu = task_cpu(p);
> ),
>
> - TP_printk("comm=%s pid=%d prio=%d target_cpu=%03d",
> + TP_printk("comm=%s pid=%d prio=%d target_cpu=%03d %s",
> __entry->comm, __entry->pid, __entry->prio,
> - __entry->target_cpu)
> + __entry->target_cpu,
> + __event_in_irq() ? "(in-irq)" : "")
> );
>
> Which produces:
>
> <idle>-0 [003] d.h4. 44.832126: sched_waking:
> comm=in:imklog pid=619 prio=120 target_cpu=006 (in-irq)
> <idle>-0 [003] d.s3. 44.832180: sched_waking:
> comm=rcu_preempt pid=15 prio=120 target_cpu=001 (in-irq)
> in:imklog-619 [006] d..2. 44.832393: sched_waking:
> comm=rs:main Q:Reg pid=620 prio=120 target_cpu=003
>
> You can see it adds "(in-irq)" when the even is executed from IRQ context
> (soft or hard irq). But I also added __event_in_hardirq() and
> __event_in_softirq() if you wanted to distinguish them.
>
> Now you don't need to update what goes into the ring buffer (and waste its
> space), but only update the output format that makes it obvious that the
> task was in interrupt context or not.
>
> I also used trace-cmd to record the events, and it still parses properly
> with no updates to libtraceevent needed.
>
> Would this work for you?
If this would work for you. Feel free to take the patch I posted and use that:
https://lore.kernel.org/all/[email protected]/
-- Steve
