mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: "Chen, Rong A" <rong.a.chen@intel.com>, Andi Kleen <ak@linux.intel.com>
Cc: Roman Sudarikov <roman.sudarikov@linux.intel.com>,
	0day robot <lkp@intel.com>,
	Alexander Antonov <alexander.antonov@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org
Subject: Re: [LKP] Re: [perf x86] b77491648e: will-it-scale.per_process_ops -2.1% regression
Date: Wed, 12 Feb 2020 10:15:41 -0500	[thread overview]
Message-ID: <c92cd67f-c2bd-7c5b-7668-7a2d64d2f8c5@linux.intel.com> (raw)
In-Reply-To: <782f409a-ff90-831c-56a0-abb3c31ab8d8@intel.com>



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@intel.com> 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@lists.01.org
>> To unsubscribe send an email to lkp-leave@lists.01.org
> 

      reply	other threads:[~2020-02-12 15:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 12:31 kernel test robot
2020-02-05 20:47 ` Andi Kleen
2020-02-06  3:07   ` [LKP] " Li, Philip
2020-02-12 10:56   ` Chen, Rong A
2020-02-12 15:15     ` Liang, Kan [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=c92cd67f-c2bd-7c5b-7668-7a2d64d2f8c5@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.antonov@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=roman.sudarikov@linux.intel.com \
    --cc=rong.a.chen@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

Powered by JetHome