Greeting,
FYI, we noticed a 210.0% improvement of fwq.fwq.med due to commit:
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
ucode: 0x7000019
Details are as below:
-------------------------------------------------------------------------------------------------->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=========================================================================================
compiler/cpufreq_governor/iterations/kconfig/nr_task/rootfs/samples/tbox_group/testcase/ucode:
gcc-7/powersave/18x/x86_64-rhel-7.6/100%/debian-x86_64-20191114.cgz/100000ss/lkp-bdw-de1/fwq/0x7000019
commit:
bc2e6521e2 ("cpufreq: Allow drivers to specify a preferred governor")
909c0e9cc1 ("cpufreq: intel_pstate: Use passive mode by default without HWP")
bc2e6521e2a44f08 909c0e9cc11ba39fa5a660583b2
---------------- ---------------------------
%stddev %change %stddev
\ | \
2906309 +210.0% 9010128 fwq.fwq.med
1397421 ± 6% +202.5% 4227573 fwq.fwq.min
1.476e+09 +3.3e+09 4.776e+09 fwq.fwq.noise.100%
2.167e+09 ± 12% +8.4e+09 1.059e+10 fwq.fwq.noise.2%
1.48e+09 +3.5e+09 5.002e+09 fwq.fwq.noise.25%
1.483e+09 +3.5e+09 5.026e+09 fwq.fwq.noise.5%
1.479e+09 +3.5e+09 4.965e+09 fwq.fwq.noise.50%
1.477e+09 +3.5e+09 4.942e+09 fwq.fwq.noise.75%
141.38 +213.1% 442.67 fwq.time.elapsed_time
141.38 +213.1% 442.67 fwq.time.elapsed_time.max
26841 ± 7% +374.8% 127444 ± 2% fwq.time.involuntary_context_switches
2201 +212.8% 6884 fwq.time.user_time
fwq.time.user_time
7000 +--------------------------------------------------------------------+
6500 |-+ |
| |
6000 |-+ |
5500 |-+ |
| |
5000 |-+ |
4500 |-+ |
4000 |-+ |
| |
3500 |-+ |
3000 |-+ |
| |
2500 |..+..+..+..+.+..+..+..+..+..+..+..+.+..+..+..+..+..+ |
2000 +--------------------------------------------------------------------+
fwq.time.elapsed_time
450 +---------------------------------------------------------------------+
| |
400 |-+ |
| |
350 |-+ |
| |
300 |-+ |
| |
250 |-+ |
| |
200 |-+ |
| |
150 |..+..+..+..+..+..+.+..+..+..+..+..+..+..+..+..+..+..+ |
| |
100 +---------------------------------------------------------------------+
fwq.time.elapsed_time.max
450 +---------------------------------------------------------------------+
| |
400 |-+ |
| |
350 |-+ |
| |
300 |-+ |
| |
250 |-+ |
| |
200 |-+ |
| |
150 |..+..+..+..+..+..+.+..+..+..+..+..+..+..+..+..+..+..+ |
| |
100 +---------------------------------------------------------------------+
fwq.fwq.min
4.5e+06 +-----------------------------------------------------------------+
| O O O O O O O O O O O O O O O O O O O O O O O |
4e+06 |-+ |
| |
3.5e+06 |-+ |
| |
3e+06 |-+ |
| |
2.5e+06 |-+ |
| |
2e+06 |-+ |
|.. |
1.5e+06 |-+ .+..+.. .+..+.. .+..+.. |
| +..+ +..+ +..+.+..+..+..+.+. + |
1e+06 +-----------------------------------------------------------------+
fwq.fwq.med
1e+07 +-------------------------------------------------------------------+
| |
9e+06 |-+O O O O O O O O O O O O O O O O O O O O O O O |
8e+06 |-+ |
| |
7e+06 |-+ |
| |
6e+06 |-+ |
| |
5e+06 |-+ |
4e+06 |-+ |
| |
3e+06 |..+..+..+.+..+..+..+..+..+.+..+..+..+..+..+.+..+..+ |
| |
2e+06 +-------------------------------------------------------------------+
fwq.fwq.noise.100_
6e+09 +-------------------------------------------------------------------+
| |
5e+09 |-+ O O O O |
| O O O O O O O O O O O O O O O O O O |
| O |
4e+09 |-+ |
| |
3e+09 |-+ |
| |
2e+09 |-+ |
| .+.. .+.. .+.. |
| +..+..+.+..+..+..+..+..+.+..+. +. +.+. + |
1e+09 |-+ |
|+ |
0 +-------------------------------------------------------------------+
fwq.fwq.noise.75_
6e+09 +-------------------------------------------------------------------+
| |
5e+09 |-+ O O O O O O O O O O O O O |
| O O O O O O O O O |
| O |
4e+09 |-+ |
| |
3e+09 |-+ |
| |
2e+09 |-+ |
| .+.. .+.. .+.. .+.. .+.. |
| +..+..+.+..+..+. +..+ +. +. +.+. + |
1e+09 |-+ |
|+ |
0 +-------------------------------------------------------------------+
fwq.fwq.noise.50_
6e+09 +-------------------------------------------------------------------+
| |
5e+09 |-+ O O O O O O O O O O O O O O |
| O O O O O O O O O |
| |
4e+09 |-+ |
| |
3e+09 |-+ |
| |
2e+09 |-+ |
| .+.. .+.. .+.. .+.. .+.. |
| +..+..+.+..+..+. +..+ +. +. +.+. + |
1e+09 |-+ |
|+ |
0 +-------------------------------------------------------------------+
fwq.fwq.noise.25_
6e+09 +-------------------------------------------------------------------+
| |
5e+09 |-+ O O O O O O O O O O O O O O O O O |
| O O O O O O |
| |
4e+09 |-+ |
| |
3e+09 |-+ |
| |
2e+09 |-+ |
| .+.. .+.. .+.. .+.. .+.. |
| +..+..+.+..+..+. +..+ +. +. +.+. + |
1e+09 |-+ |
|+ |
0 +-------------------------------------------------------------------+
fwq.fwq.noise.5_
6e+09 +-------------------------------------------------------------------+
| |
5e+09 |-+ O O O O O O O O O O O O O O O O O O |
| O O O O O |
| |
4e+09 |-+ |
| |
3e+09 |-+ |
| |
2e+09 |-+ |
| .+.. .+.. .+.. .+.. .+.. |
| +..+..+.+..+..+. +..+ +. +. +.+. + |
1e+09 |-+ |
|+ |
0 +-------------------------------------------------------------------+
fwq.fwq.noise.2_
1.2e+10 +-----------------------------------------------------------------+
| O O O |
1e+10 |-+O O O O O O O O O O O O O O O O O O O O |
| |
| |
8e+09 |-+ |
| |
6e+09 |-+ |
| |
4e+09 |-+ |
| .+.. |
| .+.. .+..+ +..+..+. .+.. .+. .+.. |
2e+09 |-++..+ +. +. +. +..+. + |
|.. |
0 +-----------------------------------------------------------------+
[*] bisect-good sample
[O] bisect-bad sample
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Rong Chen
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?
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.
user? :notice: [? +0.061763] 2020-03-04 21:15:33
user? :notice: [? +0.057012] for cpu_dir in
/sys/devices/system/cpu/cpu[0-9]*
user? :notice: [? +0.059494] do
user? :notice: [? +0.046899]??? online_file="$cpu_dir"/online
user? :notice: [? +0.074995]??? [ -f "$online_file" ] && [ "$(cat
"$online_file")" -eq 0 ] && continue
user? :notice: [? +0.080600] file="$cpu_dir"/cpufreq/scaling_governor
user? :notice: [? +0.067584]??? [ -f "$file" ] && echo "powersave" > "$file"
user? :notice: [? +0.050203] done
user? :notice: [? +0.084039]??? Internal Reference Designator: IPMI_LAN
user? :notice: [? +0.059001]??? External Reference Designator: IPMI_LAN
user? :notice: [? +0.056562] IPMI Device Information
user? :notice: [? +0.058074] BMC ARP Control???????? : ARP Responses
Enabled, Gratuitous ARP Disabled
user? :notice: [? +0.053677] 2020-03-04 21:15:34 ./t_fwq -n 100000 -w 18
-t 16
user? :notice: [Mar 4 21:22] numthreads = 16
user? :notice: [? +0.007123] thread number 1 being created.
user? :notice: [? +0.008334] thread number 2 being created.
user? :notice: [? +0.008335] thread number 3 being created.
user? :notice: [? +0.008222] thread number 4 being created.
user? :notice: [? +0.008359] thread number 5 being created.
user? :notice: [? +0.008360] thread number 6 being created.
user? :notice: [? +0.008128] thread number 7 being created.
user? :notice: [? +0.008409] thread number 8 being created.
user? :notice: [? +0.008317] thread number 9 being created.
user? :notice: [? +0.008352] thread number 10 being created.
user? :notice: [? +0.008480] thread number 11 being created.
user? :notice: [? +0.008393] thread number 12 being created.
user? :notice: [? +0.008519] thread number 13 being created.
user? :notice: [? +0.008518] thread number 14 being created.
user? :notice: [? +0.008266] thread number 15 being created.
user? :notice: [? +0.009492] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010539] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010499] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010492] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010473] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010255] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.010525] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013377] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013653] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013755] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013936] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013843] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013884] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013685] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013835] Starting FWQ_CORE with work_length = 262144
user? :notice: [? +0.013927] Starting FWQ_CORE with work_length = 262144
Best Regards,
Rong Chen
On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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?
Hi, Rafael,
"Rafael J. Wysocki" <[email protected]> writes:
> On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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?
Best Regards,
Huang, Ying
On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <[email protected]> wrote:
>
> Hi, Rafael,
>
> "Rafael J. Wysocki" <[email protected]> writes:
>
> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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.
"Rafael J. Wysocki" <[email protected]> writes:
> On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <[email protected]> wrote:
>>
>> Hi, Rafael,
>>
>> "Rafael J. Wysocki" <[email protected]> writes:
>>
>> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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? Or just pay attention to
the possible issue you pointed out?
Should we add ondemand governor?
Best Regards,
Huang, Ying
On Mon, Mar 9, 2020 at 2:17 AM Huang, Ying <[email protected]> wrote:
>
> "Rafael J. Wysocki" <[email protected]> writes:
>
> > On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <[email protected]> wrote:
> >>
> >> Hi, Rafael,
> >>
> >> "Rafael J. Wysocki" <[email protected]> writes:
> >>
> >> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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!
"Rafael J. Wysocki" <[email protected]> writes:
> On Mon, Mar 9, 2020 at 2:17 AM Huang, Ying <[email protected]> wrote:
>>
>> "Rafael J. Wysocki" <[email protected]> writes:
>>
>> > On Fri, Mar 6, 2020 at 4:29 AM Huang, Ying <[email protected]> wrote:
>> >>
>> >> Hi, Rafael,
>> >>
>> >> "Rafael J. Wysocki" <[email protected]> writes:
>> >>
>> >> > On Thu, Mar 5, 2020 at 9:18 AM Rong Chen <[email protected]> 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.
Got it! Thanks a lot for your information!
Best Regards,
Huang, Ying
> Thanks!