[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220301151744.1ad5e11a@gandalf.local.home>
Date: Tue, 1 Mar 2022 15:17:44 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jithu Joseph <jithu.joseph@...el.com>
Cc: hdegoede@...hat.com, markgross@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, corbet@....net,
gregkh@...uxfoundation.org, andriy.shevchenko@...ux.intel.com,
ashok.raj@...el.com, tony.luck@...el.com,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
platform-driver-x86@...r.kernel.org, patches@...ts.linux.dev,
ravi.v.shankar@...el.com
Subject: Re: [RFC 10/10] trace: platform/x86/intel/ifs: Add trace point to
track Intel IFS operations
On Tue, 1 Mar 2022 11:54:57 -0800
Jithu Joseph <jithu.joseph@...el.com> wrote:
> + TP_STRUCT__entry(
> + __field( u8, start )
> + __field( u8, stop )
> + __field( u64, status )
> + ),
I'd suggest swapping this to:
__field( u64, status )
__field( u8, start )
__field( u8, stop )
As trace events are usually aligned by 4 bytes (sometimes 8 for archs that
require 8byte alignment for 8 byte words), but any event, putting the
padding at the end of the event is better than in the middle of the event.
Having the u64 come after two u8 (two byes) will pretty much guarantee a 6
bytes hole in the middle of the event.
-- Steve
Powered by blists - more mailing lists