All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: 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>,
	Chen Yu <yu.c.chen@intel.com>, Rui Zhang <rui.zhang@intel.com>,
	Zhengjun Xing <zhengjun.xing@intel.com>
Subject: Re: [LKP] Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
Date: Tue, 10 Mar 2020 17:09:54 +0800	[thread overview]
Message-ID: <8736agy3rx.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <CAJZ5v0hdAnN-mu8b9g19cM8AqYGXDbs1qVxLu-qE-3P6fP1=XA@mail.gmail.com> (Rafael J. Wysocki's message of "Tue, 10 Mar 2020 09:45:57 +0100")

"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!

WARNING: multiple messages have this Message-ID (diff)
From: Huang, Ying <ying.huang@intel.com>
To: lkp@lists.01.org
Subject: Re: [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement
Date: Tue, 10 Mar 2020 17:09:54 +0800	[thread overview]
Message-ID: <8736agy3rx.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <CAJZ5v0hdAnN-mu8b9g19cM8AqYGXDbs1qVxLu-qE-3P6fP1=XA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3812 bytes --]

"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!

  reply	other threads:[~2020-03-10  9:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05  1:35 [cpufreq] 909c0e9cc1: fwq.fwq.med 210.0% improvement kernel test robot
2020-03-05  1:35 ` kernel test robot
2020-03-05  7:50 ` Rafael J. Wysocki
2020-03-05  7:50   ` Rafael J. Wysocki
2020-03-05  8:18   ` Rong Chen
2020-03-05  8:18     ` Rong Chen
2020-03-05  9:05     ` [Devel] " Rafael J. Wysocki
2020-03-05  9:05       ` Rafael J. Wysocki
2020-03-05  9:05       ` Rafael J. Wysocki
2020-03-06  3:29       ` [LKP] " Huang, Ying
2020-03-06  3:29         ` Huang, Ying
2020-03-06  9:54         ` [Devel] Re: [LKP] " Rafael J. Wysocki
2020-03-06  9:54           ` Rafael J. Wysocki
2020-03-06  9:54           ` [LKP] " Rafael J. Wysocki
2020-03-09  1:17           ` Huang, Ying
2020-03-09  1:17             ` Huang, Ying
2020-03-10  8:45             ` [Devel] Re: [LKP] " Rafael J. Wysocki
2020-03-10  8:45               ` Rafael J. Wysocki
2020-03-10  8:45               ` [LKP] " Rafael J. Wysocki
2020-03-10  9:09               ` Huang, Ying [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=8736agy3rx.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --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=rafael@kernel.org \
    --cc=rong.a.chen@intel.com \
    --cc=rui.zhang@intel.com \
    --cc=yu.c.chen@intel.com \
    --cc=zhengjun.xing@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.