Linux Perf Users
 help / color / mirror / Atom feed
From: Dapeng Mi <dapeng1.mi@linux.intel.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Zhenyu Wang <zhenyuw@linux.intel.com>,
	Zhang Tinghao <tinghao.zhang@intel.com>,
	Zhuocheng Ding <zhuocheng.ding@intel.com>
Subject: Re: [PATCH] perf/x86/intel: Define bit macros for FixCntrCtl MSR
Date: Fri, 31 Mar 2023 13:40:11 +0800	[thread overview]
Message-ID: <ZCZyOyvfNgKsYVLy@dmi-pnp-i7> (raw)
In-Reply-To: <2bba1909-dac8-321f-e685-a793f1a4e170@linux.intel.com>

On Thu, Mar 30, 2023 at 10:46:01AM -0400, Liang, Kan wrote:
> Date: Thu, 30 Mar 2023 10:46:01 -0400
> From: "Liang, Kan" <kan.liang@linux.intel.com>
> Subject: Re: [PATCH] perf/x86/intel: Define bit macros for FixCntrCtl MSR
> 
> 
> 
> On 2023-03-30 9:07 a.m., Peter Zijlstra wrote:
> > On Thu, Mar 30, 2023 at 09:28:46AM +0800, Dapeng Mi wrote:
> >> Define bit macros for FixCntrCtl MSR and replace the bit hardcoding
> >> with these bit macros. This would make code be more human-readable.
> >>
> >> Perf commands 'perf stat -e "instructions,cycles,ref-cycles"' and
> >> 'perf record -e "instructions,cycles,ref-cycles"' pass.
> >>
> >> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> >> ---
> >>  arch/x86/events/intel/core.c      | 18 +++++++++---------
> >>  arch/x86/include/asm/perf_event.h | 10 ++++++++++
> >>  2 files changed, 19 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> >> index 070cc4ef2672..b7c0bb78ed59 100644
> >> --- a/arch/x86/events/intel/core.c
> >> +++ b/arch/x86/events/intel/core.c
> >> @@ -2451,7 +2451,7 @@ static void intel_pmu_disable_fixed(struct perf_event *event)
> >>  
> >>  	intel_clear_masks(event, idx);
> >>  
> >> -	mask = 0xfULL << ((idx - INTEL_PMC_IDX_FIXED) * 4);
> >> +	mask = intel_fixed_bits(idx - INTEL_PMC_IDX_FIXED, INTEL_FIXED_BITS_MASK);
> >>  	cpuc->fixed_ctrl_val &= ~mask;
> > 
> > So maybe it's me, but I find the original far easier to read :/ That new
> > things I need to look up every single identifier before I can tell wth
> > it does.
> 
> The intel_fixed_bits() tries to replace the duplicate "bit << (idx *
> 4);". I think it should be a good improvement. Maybe we should rename it
> to intel_shift_fixed_bits_by_idx(). Is it better?
> 
> If not, I think at least we should use some macros to replace the magic
> number.
> 
> Thanks,
> Kan

Comparing previous magic numbers, the following macros can help developers
to know the meaning of the piece of code rapidly and don't need to
check the hardware specs and get its meaning, and developers could more
easily confirm his code logic is correct and don't confirm with spec
again.

+#define INTEL_FIXED_0_KERNEL				(1ULL << 0)
+#define INTEL_FIXED_0_USER				(1ULL << 1)
+#define INTEL_FIXED_0_ANYTHREAD			(1ULL << 2)
+#define INTEL_FIXED_0_ENABLE_PMI			(1ULL << 3)

As for the macro intel_fixed_bits, it indeed hides some details, but it
make the code looks cleaner and developer can use it more easily and don't
worry about the details. Like what Kan said, maybe we can get a new name to
make it be more understandably. 
-- 
Thanks,
Dapeng Mi

      reply	other threads:[~2023-03-31  5:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30  1:28 [PATCH] perf/x86/intel: Define bit macros for FixCntrCtl MSR Dapeng Mi
2023-03-30 13:07 ` Peter Zijlstra
2023-03-30 14:46   ` Liang, Kan
2023-03-31  5:40     ` Dapeng Mi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZCZyOyvfNgKsYVLy@dmi-pnp-i7 \
    --to=dapeng1.mi@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tinghao.zhang@intel.com \
    --cc=x86@kernel.org \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhuocheng.ding@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox