linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Huang Rui <ray.huang@amd.com>
To: Giovanni Gherdovich <ggherdovich@suse.cz>
Cc: "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Borislav Petkov <bp@suse.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Sharma, Deepak" <Deepak.Sharma@amd.com>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Limonciello, Mario" <Mario.Limonciello@amd.com>,
	Steven Noonan <steven@valvesoftware.com>,
	"Fontenot, Nathan" <Nathan.Fontenot@amd.com>,
	"Su, Jinzhou (Joe)" <Jinzhou.Su@amd.com>,
	"Du, Xiaojian" <Xiaojian.Du@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v4 06/22] cpufreq: amd: introduce a new amd pstate driver to support future processors
Date: Fri, 26 Nov 2021 17:44:06 +0800	[thread overview]
Message-ID: <YaCsZqIl4+Dbefg7@amd.com> (raw)
In-Reply-To: <dbb61b3a2602150aa091d3b456c1866a580e3c53.camel@suse.cz>

On Thu, Nov 25, 2021 at 11:03:58PM +0800, Giovanni Gherdovich wrote:
> On Fri, 2021-11-19 at 18:30 +0800, Huang Rui wrote:
> > <snip>
> >
> > Performance Per Watt (PPW) Calculation:
> > 
> > The PPW calculation is referred by below paper:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoftware.intel.com%2Fcontent%2Fdam%2Fdevelop%2Fexternal%2Fus%2Fen%2Fdocuments%2Fperformance-per-what-paper.pdf&amp;data=04%7C01%7Cray.huang%40amd.com%7C65f95f752ce142a5356d08d9b024d0de%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637734494579654964%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6SzLLzQ1mRlbxdO1skcnrjulOmaqGWCrtDpIZToVjMM%3D&amp;reserved=0
> > 
> > Below formula is referred from below spec to measure the PPW:
> > 
> > (F / t) / P = F * t / (t * E) = F / E,
> > 
> > "F" is the number of frames per second.

This "F" should be the number of frames, not per second.

> > "P" is power measured in watts.
> > "E" is energy measured in joules.
> 
> Hello, I'd appreciate if you can remove the reference to the above paper and
> formula, because it is not really relevant to this context, and ends up being
> confusing.
> 
> It describes performance per watt tailored to graphics benchmarks, in the form
> of frames per joule. Nothing wrong with that, but it only works for tests that
> measure frames per second, and none of the tests below is of that type.

OK, actually, we would test 3D steam game benchmarks as well on our
processors with amd-pstate. :-)

And yes, below three benchmark tests are not related with "frame", but the
"MB" or "runs" of speedometer are actually another meaning of "frame" which
represent the performance data on each benchmark, right. That's is original
reason to put paper and formula here.

If you think it may confuse any guys, I can remove this in next version.

> 
> You have:
> 
> - tbench measures throughput (MB/sec)
> - gitsource, aka run the git test suite, measures elapsed time
> - speedometer, a web browser test that gives "runs per minute"
> 
> If you want performance per watt, you need to express your result as
> "operations per second", where "operations" is up to you to define. For
> tbench, one "operation" is moving a MB of data. For speedometer, one
> "operation" is one "run", as defined in the benchmark. Once you have op/sec
> (aka performance), divide by the average power measured over the entire
> duration of the benchmark.
> 
> In cases like gitsource, where you have elapsed_time as a result, performance
> per watt is 1 / (elapsed_time * average_power).
> 

The "operations" you mentioned here is another meaning of "frames" at the
paper in general. That's actual my previous purpose. :-)

> > We use the RAPL interface with "perf" tool to get the energy data of the
> > package power.
> > 
> > The data comparisons between amd-pstate and acpi-freq module are tested on
> > AMD Cezanne processor:
> > 
> > 1) TBench CPU benchmark:
> > 
> > +---------------------------------------------------------------------+
> > >                                                                     |
> > >               TBench (Performance Per Watt)                         |
> > >                                                    Higher is better |
> > +-------------------+------------------------+------------------------+
> > >                   |  Performance Per Watt  |  Performance Per Watt  |
> > >   Kernel Module   |       (Schedutil)      |       (Ondemand)       |
> > >                   |  Unit: MB / (s * J)    |  Unit: MB / (s * J)    |
> 
> The unit "MB / (s * J)" doesn't really work, it should be "MB / (sec * watt)".
> Can you double check that you divided the performance result by the average
> power? Same for the other tests.
> 
> It is also relevant to show performance, alongside with perf-per-watt.
> 

Aligned with you offline before, we will update the new performance per
watt data here with MB / Joule. Thanks to point it out.

Thanks,
Ray

  reply	other threads:[~2021-11-26  9:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 10:30 [PATCH v4 00/22] cpufreq: introduce a new AMD CPU frequency control mechanism Huang Rui
2021-11-19 10:30 ` [PATCH v4 01/22] x86/cpufreatures: add AMD Collaborative Processor Performance Control feature flag Huang Rui
2021-11-19 10:30 ` [PATCH v4 02/22] x86/msr: add AMD CPPC MSR definitions Huang Rui
2021-11-19 10:30 ` [PATCH v4 03/22] ACPI: CPPC: implement support for SystemIO registers Huang Rui
2021-11-19 10:30 ` [PATCH v4 04/22] ACPI: CPPC: Check present CPUs for determining _CPC is valid Huang Rui
2021-11-19 10:30 ` [PATCH v4 05/22] ACPI: CPPC: add cppc enable register function Huang Rui
2021-11-19 10:30 ` [PATCH v4 06/22] cpufreq: amd: introduce a new amd pstate driver to support future processors Huang Rui
2021-11-19 10:46   ` Peter Zijlstra
2021-11-19 11:16     ` Huang Rui
2021-11-19 12:58       ` Peter Zijlstra
2021-11-25 15:03   ` Giovanni Gherdovich
2021-11-26  9:44     ` Huang Rui [this message]
2021-11-19 10:30 ` [PATCH v4 07/22] cpufreq: amd: add fast switch function for amd-pstate Huang Rui
2021-11-19 10:30 ` [PATCH v4 08/22] cpufreq: amd: introduce the support for the processors with shared memory solution Huang Rui
2021-11-19 10:30 ` [PATCH v4 09/22] cpufreq: amd: add trace for amd-pstate module Huang Rui
2021-11-19 10:30 ` [PATCH v4 10/22] cpufreq: amd: add boost mode support for amd-pstate Huang Rui
2021-11-19 10:30 ` [PATCH v4 11/22] cpufreq: amd: add amd-pstate frequencies attributes Huang Rui
2021-11-19 10:30 ` [PATCH v4 12/22] cpufreq: amd: add amd-pstate performance attributes Huang Rui
2021-11-19 10:30 ` [PATCH v4 13/22] cpupower: add AMD P-state capability flag Huang Rui
2021-11-19 10:30 ` [PATCH v4 14/22] cpupower: add the function to check amd-pstate enabled Huang Rui
2021-11-19 10:30 ` [PATCH v4 15/22] cpupower: initial AMD P-state capability Huang Rui
2021-11-19 10:30 ` [PATCH v4 16/22] cpupower: add the function to get the sysfs value from specific table Huang Rui
2021-11-19 20:38   ` Nathan Fontenot
2021-11-19 22:19     ` Juuso Alasuutari
2021-11-22  2:41       ` Huang Rui
2021-11-19 10:30 ` [PATCH v4 17/22] cpupower: introduce acpi cppc library Huang Rui
2021-11-19 10:30 ` [PATCH v4 18/22] cpupower: add amd-pstate sysfs definition and access helper Huang Rui
2021-11-19 10:30 ` [PATCH v4 19/22] cpupower: enable boost state support for amd-pstate module Huang Rui
2021-11-19 10:31 ` [PATCH v4 20/22] cpupower: move print_speed function into misc helper Huang Rui
2021-11-19 10:31 ` [PATCH v4 21/22] cpupower: print amd-pstate information on cpupower Huang Rui
2021-11-19 10:31 ` [PATCH v4 22/22] Documentation: amd-pstate: add amd-pstate driver introduction Huang Rui

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=YaCsZqIl4+Dbefg7@amd.com \
    --to=ray.huang@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Deepak.Sharma@amd.com \
    --cc=Jinzhou.Su@amd.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=Nathan.Fontenot@amd.com \
    --cc=Xiaojian.Du@amd.com \
    --cc=bp@suse.de \
    --cc=ggherdovich@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=skhan@linuxfoundation.org \
    --cc=steven@valvesoftware.com \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    /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).