On Mon, Mar 9, 2020 at 2:17 AM Huang, Ying <ying.huang@xxxxxxxxx> wrote:
>
> "Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:
>
> > On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <ying.huang@xxxxxxxxx> wrote:
> >>
> >> Hi, Rafael,
> >>
> >> "Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:
> >>
> >> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <rong.a.chen@xxxxxxxxx> 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!
