lkml.org 
[lkml]   [2022]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] KVM: x86/pmu: Avoid ternary operator by directly referring to counters->type
From
On 7/12/2022 1:19 am, Sean Christopherson wrote:
> On Tue, Dec 06, 2022, Like Xu wrote:
>>>> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
>>>> index e5cec07ca8d9..28b0a784f6e9 100644
>>>> --- a/arch/x86/kvm/vmx/pmu_intel.c
>>>> +++ b/arch/x86/kvm/vmx/pmu_intel.c
>>>> @@ -142,7 +142,7 @@ static struct kvm_pmc *intel_rdpmc_ecx_to_pmc(struct kvm_vcpu *vcpu,
>>>> }
>>>> if (idx >= num_counters)
>>>> return NULL;
>>>> - *mask &= pmu->counter_bitmask[fixed ? KVM_PMC_FIXED : KVM_PMC_GP];
>>>> + *mask &= pmu->counter_bitmask[counters->type];
>>>
>>> In terms of readability, I have a slight preference for the current code as I

IMO, using counters->type directly just like pmc_bitmask() will add more readability
and opportunistically helps some stale compilers behave better.

>>> don't have to look at counters->type to understand its possible values.
>> When someone tries to add a new type of pmc type, the code bugs up.
>
> Are there new types coming along? If so, I definitely would not object to refactoring
> this code in the context of a series that adds a new type(s). But "fixing" this one
> case is not sufficient to support a new type, e.g. intel_is_valid_rdpmc_ecx() also
> needs to be updated. Actually, even this function would need additional updates
> to perform a similar sanity check.

True but this part of the change is semantically relevant, which should not
be present in a harmless generic optimization like this one. Right ?

>
> if (fixed) {
> counters = pmu->fixed_counters;
> num_counters = pmu->nr_arch_fixed_counters;
> } else {
> counters = pmu->gp_counters;
> num_counters = pmu->nr_arch_gp_counters;
> }
> if (idx >= num_counters)
> return NULL;
>
>> And, this one will make all usage of pmu->counter_bitmask[] more consistent.
>
> How's that? There's literally one instance of using ->type
>
> static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
> {
> struct kvm_pmu *pmu = pmc_to_pmu(pmc);
>
> return pmu->counter_bitmask[pmc->type];
> }
>
> everything else is hardcoded. And using pmc->type there make perfect sense in
> that case. But in intel_rdpmc_ecx_to_pmc(), there is already usage of "fixed",
> so IMO switching to ->type makes that function somewhat inconsistent with itself.

More, it's rare to see code like " [ a ? b : c] " in the world of both KVM and x86.
Good practice (branchless) should be scattered everywhere and not the other way
around.

I have absolutely no objection to your "slight preference". Thanks for your time
in reviewing this.

\
 
 \ /
  Last update: 2022-12-07 09:45    [W:0.047 / U:2.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site