From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Rong Chen <rong.a.chen@intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"open list:ACPI COMPONENT ARCHITECTURE (ACPICA)"
<devel@acpica.org>, Linux PM <linux-pm@vger.kernel.org>,
lkp@lists.01.org, Andi Kleen <andi.kleen@intel.com>
Subject: Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
Date: Tue, 10 Mar 2020 09:45:57 +0100 [thread overview]
Message-ID: <CAJZ5v0hdAnN-mu8b9g19cM8AqYGXDbs1qVxLu-qE-3P6fP1=XA@mail.gmail.com> (raw)
In-Reply-To: <87imjez5rl.fsf@yhuang-dev.intel.com>
On Mon, Mar 9, 2020 at 2:17 AM Huang, Ying <ying.huang@intel.com> wrote:
>
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>
> > On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <ying.huang@intel.com> wrote:
> >>
> >> Hi, Rafael,
> >>
> >> "Rafael J. Wysocki" <rafael@kernel.org> writes:
> >>
> >> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <rong.a.chen@intel.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 3/5/20 3:50 PM, Rafael J. Wysocki wrote:
> >> >> > On 3/5/2020 2:35 AM, kernel test robot wrote:
> >> >> >> Greeting,
> >> >> >>
> >> >> >> FYI, we noticed a 210.0% improvement of fwq.fwq.med due to commit:
> >> >> >
> >> >> > Well, that sounds impressive. :-)
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> commit: 909c0e9cc11ba39fa5a660583b25c2431cf54deb ("cpufreq:
> >> >> >> intel_pstate: Use passive mode by default without HWP")
> >> >> >> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git
> >> >> >> intel_pstate-passive
> >> >> >>
> >> >> >> in testcase: fwq
> >> >> >> on test machine: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
> >> >> >> with 48G memory
> >> >> >> with following parameters:
> >> >> >>
> >> >> >> nr_task: 100%
> >> >> >> samples: 100000ss
> >> >> >> iterations: 18x
> >> >> >> cpufreq_governor: powersave
> >> >> >
> >> >> > The governor should be schedutil, though, unless it is explicitly set
> >> >> > to powersave in the test environment.
> >> >> >
> >> >> > Is that the case?
> >> >> >
> >> >> >
> >> >>
> >> >> Hi Rafael,
> >> >>
> >> >> Yes, we set to powersave for this test.
> >> >
> >> > I wonder why this is done? Is there any particular technical reason
> >> > for doing that?
> >>
> >> fwq is a noise benchmark to measure the hardware and software noise
> >> level. More information could be found in the following document.
> >>
> >> https://asc.llnl.gov/sequoia/benchmarks/FTQ_summary_v1.1.pdf
> >>
> >> In 0day, to measure the noise introduced by power management, we will
> >> run fwq with the performance and powersave governors. Do you think this
> >> is reasonable? Or we should use some other governors?
> >
> > I think that the schedutil governor should be tested too if present.
> >
> > Also note that for the intel_pstate driver "powersave" may mean
> > different things depending on the current operation mode of the
> > driver. If scaling_driver is "intel_pstate", then "powersave" is the
> > driver's built-in algorithm. If scaling_driver is "intel_cpufreq",
> > though, "powersave" means running at the minimum frequency all the
> > time.
>
> Thanks for your guidance. We will test schedutil governor in the future
> too.
>
> As for powersave, should we stop testing it?
You cannot stop testing it, because it is the default governor
algorithm for intel_pstate working in the active mode.
> Or just pay attention to the possible issue you pointed out?
Yes, please!
Basically, I would recommend to test the following configurations by default:
(1) scaling_driver = intel_pstate + scaling_governor = powersave
(2) scaling_driver = intel_cpufreq + scaling_governor = schedutil
The other ones are kind of less interesting.
[Note that in order to switch over from intel_pstate to intel_cpufreq,
you need to write "passive" into
/sys/devices/system/cpu/intel_pstate/status and if that write fails,
configuration (2) is not available and may be skipped.]
> Should we add ondemand governor?
Not necessarily, maybe as a reference only if you have spare cycles.
Thanks!
next prev parent reply other threads:[~2020-03-10 8:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200305013509.GF5972@shao2-debian>
2020-03-05 7:50 ` [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement Rafael J. Wysocki
2020-03-05 8:18 ` Rong Chen
2020-03-05 9:05 ` Rafael J. Wysocki
2020-03-06 3:29 ` [LKP] " Huang, Ying
2020-03-06 9:54 ` Rafael J. Wysocki
2020-03-09 1:17 ` Huang, Ying
2020-03-10 8:45 ` Rafael J. Wysocki [this message]
2020-03-10 9:09 ` Huang, Ying
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='CAJZ5v0hdAnN-mu8b9g19cM8AqYGXDbs1qVxLu-qE-3P6fP1=XA@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=andi.kleen@intel.com \
--cc=devel@acpica.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lkp@lists.01.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rong.a.chen@intel.com \
--cc=ying.huang@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;
as well as URLs for NNTP newsgroup(s).