Messages in this thread | | | Date | Mon, 6 Feb 2023 11:40:53 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 5/5] platform/x86/intel/ifs: Trace support for array test |
| |
On Tue, 31 Jan 2023 15:43:02 -0800 Jithu Joseph <jithu.joseph@intel.com> wrote:
> diff --git a/include/trace/events/intel_ifs.h b/include/trace/events/intel_ifs.h > index d7353024016c..db43df4139a2 100644 > --- a/include/trace/events/intel_ifs.h > +++ b/include/trace/events/intel_ifs.h > @@ -35,6 +35,33 @@ TRACE_EVENT(ifs_status, > __entry->status) > ); > > +TRACE_EVENT(ifs_array, > + > + TP_PROTO(int cpu, union ifs_array activate, union ifs_array status), > + > + TP_ARGS(cpu, activate, status), > + > + TP_STRUCT__entry( > + __field( u64, status ) > + __field( int, cpu ) > + __field( u32, arrays ) > + __field( u16, bank ) > + ), > + > + TP_fast_assign( > + __entry->cpu = cpu; > + __entry->arrays = activate.array_bitmask; > + __entry->bank = activate.array_bank;
Regardless of the "bitfield" discussion on the other patches, this part is considered a fast path (although if where it is called, then it may not be). I would just have:
__field( u64, data )
__entry->data = status.data;
> + __entry->status = status.data; > + ), > + > + TP_printk("cpu: %d, array_list: %.8x, array_bank: %.4x, status: %.16llx", > + __entry->cpu,
> + __entry->arrays, > + __entry->bank,
__entry->data >> 32, (__entry->data >> 16) & 0xffff,
Or something similar. That is, move the parsing of the bits to the output. libtraceevent should still be able to handle this.
-- Steve
> + __entry->status) > +); > +
| |