Re: [PATCH 5/5] platform/x86/intel/ifs: Trace support for array test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 31 Jan 2023 15:43:02 -0800
Jithu Joseph <jithu.joseph@xxxxxxxxx> 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)
> +);
> +



[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux