Re: [LKP] Re: [perf x86] b77491648e: will-it-scale.per_process_ops -2.1% regression

[Liang, Kan]

On 2/12/2020 5:56 AM, Chen, Rong A wrote:
> On 2/6/2020 4:47 AM, Andi Kleen wrote:
> > kernel test robot <rong.a.chen@xxxxxxxxx> writes:
> >
> > > Greeting,
> > >
> > > FYI, we noticed a -2.1% regression of will-it-scale.per_process_ops 
> > > due to commit:
> > >
> > >
> > > commit: b77491648e6eb2f26b6edf5eaea859adc17f4dcc ("perf x86: 
> > > Infrastructure for exposing an Uncore unit to PMON mapping")
> > > https://github.com/0day-ci/linux/commits/roman-sudarikov-linux-intel-com/perf-x86-Exposing-IO-stack-to-IO-PMON-mapping-through-sysfs/20200118-075508 
> > Seems to be spurious bisect. I don't think that commit could change
> > anything performance related.
>
> Hi Andi,
>
> I commented out some lines in arch/x86/events/intel/uncore.c and 
> will-it-scale.per_process_ops increased.
>
> commit:
>  Â v5.4
>  Â b77491648e ("perf x86: Infrastructure for exposing an Uncore unit to 
> PMON mapping")
>  Â f33fe1b258 ("test")
>
>
>  ÂÂÂÂÂÂÂÂÂÂÂ v5.4Â b77491648e6eb2f26b6edf5eae 
> f33fe1b258b2a4b2fc97600b2b testcase/testparams/testbox
> ----------------Â -------------------------- -------------------------- 
> ---------------------------
>  ÂÂÂÂÂÂÂÂ %stddevÂÂÂÂÂ changeÂÂÂÂÂÂÂÂ %stddevÂÂÂÂÂ change %stddev
>  ÂÂÂÂÂÂÂÂÂÂÂÂ \ÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ \ÂÂÂÂÂÂÂÂÂ | \
>  ÂÂÂÂ 47983ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 47004 47647 
> will-it-scale/performance-process-100%-signal1-ucode=0xb000038/lkp-bdw-ep6
>  ÂÂÂÂ 47983ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 47004 47647ÂÂÂÂÂÂÂ GEO-MEAN 
> will-it-scale.per_process_ops
>
> diff --git a/arch/x86/events/intel/uncore.c 
> b/arch/x86/events/intel/uncore.c
> index 55201bfde2c84c..0dc9c455423d99 100644
> --- a/arch/x86/events/intel/uncore.c
> +++ b/arch/x86/events/intel/uncore.c
> @@ -887,7 +887,7 @@ static int uncore_pmu_register(struct 
> intel_uncore_pmu *pmu)
>  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ pmu->pmu.attr_groups = pmu->type->attr_groups;
>  ÂÂÂÂÂÂÂ }
>
> -ÂÂÂÂÂÂ pmu->pmu.attr_update = attr_update;
> +ÂÂÂÂÂÂ // pmu->pmu.attr_update = attr_update;
>
>  ÂÂÂÂÂÂÂ if (pmu->type->num_boxes == 1) {
>  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ if (strlen(pmu->type->name) > 0)
> @@ -903,7 +903,7 @@ static int uncore_pmu_register(struct 
> intel_uncore_pmu *pmu)
>  ÂÂÂÂÂÂÂÂ * Exposing mapping of Uncore units to corresponding Uncore PMUs
>  ÂÂÂÂÂÂÂÂ * through /sys/devices/uncore_<type>_<idx>/mapping
>  ÂÂÂÂÂÂÂÂ */
> -ÂÂÂÂÂÂ uncore_platform_mapping(pmu->type);
> +ÂÂÂÂÂÂ // uncore_platform_mapping(pmu->type);

The patch is for SKX uncore. The test machine looks like a BDX.
So the mapping_group should always be invisible.
The attr_update should not update.
I think there should be no performance impact.

static void uncore_platform_mapping(struct intel_uncore_type *t)
{
	if (t->get_topology && t->set_mapping &&
	    !t->get_topology(t, max_dies) && !t->set_mapping(t, max_dies))
		mapping_group.is_visible = NULL;
	else
		mapping_group.is_visible = not_visible;
}

Kan

>  ÂÂÂÂÂÂÂ ret = perf_pmu_register(&pmu->pmu, pmu->name, -1);
>  ÂÂÂÂÂÂÂ if (!ret)
>
> Best Regards,
> Rong Chen
>
> > -Andi
> > _______________________________________________
> > LKP mailing list -- lkp@xxxxxxxxxxxx
> > To unsubscribe send an email to lkp-leave@xxxxxxxxxxxx