Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 31 Mar 2023 13:40:11 +0800
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
Message-ID: <ZCZyOyvfNgKsYVLy@dmi-pnp-i7>
References: <20230330012846.2927220-1-dapeng1.mi@linux.intel.com>
 <20230330130702.GF124812@hirez.programming.kicks-ass.net>
 <2bba1909-dac8-321f-e685-a793f1a4e170@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2bba1909-dac8-321f-e685-a793f1a4e170@linux.intel.com>
Precedence: bulk

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