lkml.org 
[lkml]   [2023]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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)
    > +);
    > +

    \
     
     \ /
      Last update: 2023-03-27 00:11    [W:4.345 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site