linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
       [not found] <20200305013509.GF5972@shao2-debian>
@ 2020-03-05  7:50 ` Rafael J. Wysocki
  2020-03-05  8:18   ` Rong Chen
  0 siblings, 1 reply; 8+ messages in thread
From: Rafael J. Wysocki @ 2020-03-05  7:50 UTC (permalink / raw)
  To: kernel test robot; +Cc: LKML, linux-acpi, devel, linux-pm, lkp, Rafael Wysocki

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?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  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
  0 siblings, 1 reply; 8+ messages in thread
From: Rong Chen @ 2020-03-05  8:18 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: LKML, linux-acpi, devel, linux-pm, lkp, Rafael Wysocki



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-05  8:18   ` Rong Chen
@ 2020-03-05  9:05     ` Rafael J. Wysocki
  2020-03-06  3:29       ` [LKP] " Huang, Ying
  0 siblings, 1 reply; 8+ messages in thread
From: Rafael J. Wysocki @ 2020-03-05  9:05 UTC (permalink / raw)
  To: Rong Chen
  Cc: Rafael J. Wysocki, LKML, ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Rafael Wysocki

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?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-05  9:05     ` Rafael J. Wysocki
@ 2020-03-06  3:29       ` Huang, Ying
  2020-03-06  9:54         ` Rafael J. Wysocki
  0 siblings, 1 reply; 8+ messages in thread
From: Huang, Ying @ 2020-03-06  3:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rong Chen, Rafael J. Wysocki, LKML, ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Andi Kleen

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?

Best Regards,
Huang, Ying

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-06  3:29       ` [LKP] " Huang, Ying
@ 2020-03-06  9:54         ` Rafael J. Wysocki
  2020-03-09  1:17           ` Huang, Ying
  0 siblings, 1 reply; 8+ messages in thread
From: Rafael J. Wysocki @ 2020-03-06  9:54 UTC (permalink / raw)
  To: Huang, Ying
  Cc: Rafael J. Wysocki, Rong Chen, Rafael J. Wysocki, LKML,
	ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Andi Kleen

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-06  9:54         ` Rafael J. Wysocki
@ 2020-03-09  1:17           ` Huang, Ying
  2020-03-10  8:45             ` Rafael J. Wysocki
  0 siblings, 1 reply; 8+ messages in thread
From: Huang, Ying @ 2020-03-09  1:17 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rong Chen, Rafael J. Wysocki, LKML, ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Andi Kleen

"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?  Or just pay attention to
the possible issue you pointed out?

Should we add ondemand governor?

Best Regards,
Huang, Ying

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-09  1:17           ` Huang, Ying
@ 2020-03-10  8:45             ` Rafael J. Wysocki
  2020-03-10  9:09               ` Huang, Ying
  0 siblings, 1 reply; 8+ messages in thread
From: Rafael J. Wysocki @ 2020-03-10  8:45 UTC (permalink / raw)
  To: Huang, Ying
  Cc: Rafael J. Wysocki, Rong Chen, Rafael J. Wysocki, LKML,
	ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Andi Kleen

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!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
  2020-03-10  8:45             ` Rafael J. Wysocki
@ 2020-03-10  9:09               ` Huang, Ying
  0 siblings, 0 replies; 8+ messages in thread
From: Huang, Ying @ 2020-03-10  9:09 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rong Chen, Rafael J. Wysocki, LKML, ACPI Devel Maling List,
	open list:ACPI COMPONENT ARCHITECTURE (ACPICA),
	Linux PM, lkp, Andi Kleen, Chen Yu, Rui Zhang, Zhengjun Xing

"Rafael J. Wysocki" <rafael@kernel.org> writes:

> 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.

Got it!  Thanks a lot for your information!

Best Regards,
Huang, Ying

> Thanks!

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-03-10  9:09 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
2020-03-10  9:09               ` Huang, Ying

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).