[PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency transition delay time

Perry Yuan posted 7 patches 3 years, 7 months ago
[PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency transition delay time
Posted by Perry Yuan 3 years, 7 months ago
Change the default transition latency to be 20ms that is more
reasonable transition delay for AMD processors in non-EPP driver mode.

Update transition delay time to 1ms, in the AMD CPU autonomous mode and
non-autonomous mode, CPPC firmware will decide frequency at 1ms timescale
based on the workload utilization.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
---
 drivers/cpufreq/amd-pstate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index e40177d14310..9cb051d61422 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -41,8 +41,8 @@
 #include <asm/msr.h>
 #include "amd-pstate-trace.h"
 
-#define AMD_PSTATE_TRANSITION_LATENCY	0x20000
-#define AMD_PSTATE_TRANSITION_DELAY	500
+#define AMD_PSTATE_TRANSITION_LATENCY	20000
+#define AMD_PSTATE_TRANSITION_DELAY	1000
 
 /*
  * TODO: We need more time to fine tune processors with shared memory solution
-- 
2.34.1
Re: [PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency transition delay time
Posted by Punit Agrawal 3 years, 7 months ago
Perry Yuan <Perry.Yuan@amd.com> writes:

> Change the default transition latency to be 20ms that is more
> reasonable transition delay for AMD processors in non-EPP driver mode.
>
> Update transition delay time to 1ms, in the AMD CPU autonomous mode and
> non-autonomous mode, CPPC firmware will decide frequency at 1ms timescale
> based on the workload utilization.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
> ---
>  drivers/cpufreq/amd-pstate.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index e40177d14310..9cb051d61422 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -41,8 +41,8 @@
>  #include <asm/msr.h>
>  #include "amd-pstate-trace.h"
>  
> -#define AMD_PSTATE_TRANSITION_LATENCY	0x20000
> -#define AMD_PSTATE_TRANSITION_DELAY	500
> +#define AMD_PSTATE_TRANSITION_LATENCY	20000
> +#define AMD_PSTATE_TRANSITION_DELAY	1000

How were these values derived? If from documentation, it'll be good to
add a link to the relevant documentation. And if they were derived from
testing, please mention this in the commit log (along with some details
of the tests used to determine the value).

>  
>  /*
>   * TODO: We need more time to fine tune processors with shared memory solution
RE: [PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency transition delay time
Posted by Yuan, Perry 3 years, 7 months ago
[AMD Official Use Only - General]

Hi Punit

> -----Original Message-----
> From: Punit Agrawal <punit.agrawal@bytedance.com>
> Sent: Monday, August 15, 2022 11:06 PM
> To: Yuan, Perry <Perry.Yuan@amd.com>
> Cc: rafael.j.wysocki@intel.com; Huang, Ray <Ray.Huang@amd.com>;
> viresh.kumar@linaro.org; Sharma, Deepak <Deepak.Sharma@amd.com>;
> Limonciello, Mario <Mario.Limonciello@amd.com>; Fontenot, Nathan
> <Nathan.Fontenot@amd.com>; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Su, Jinzhou (Joe) <Jinzhou.Su@amd.com>;
> Huang, Shimmer <Shimmer.Huang@amd.com>; Du, Xiaojian
> <Xiaojian.Du@amd.com>; Meng, Li (Jassmine) <Li.Meng@amd.com>; linux-
> pm@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency
> transition delay time
> 
> [CAUTION: External Email]
> 
> Perry Yuan <Perry.Yuan@amd.com> writes:
> 
> > Change the default transition latency to be 20ms that is more
> > reasonable transition delay for AMD processors in non-EPP driver mode.
> >
> > Update transition delay time to 1ms, in the AMD CPU autonomous mode
> > and non-autonomous mode, CPPC firmware will decide frequency at 1ms
> > timescale based on the workload utilization.
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
> > ---
> >  drivers/cpufreq/amd-pstate.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpufreq/amd-pstate.c
> > b/drivers/cpufreq/amd-pstate.c index e40177d14310..9cb051d61422 100644
> > --- a/drivers/cpufreq/amd-pstate.c
> > +++ b/drivers/cpufreq/amd-pstate.c
> > @@ -41,8 +41,8 @@
> >  #include <asm/msr.h>
> >  #include "amd-pstate-trace.h"
> >
> > -#define AMD_PSTATE_TRANSITION_LATENCY        0x20000
> > -#define AMD_PSTATE_TRANSITION_DELAY  500
> > +#define AMD_PSTATE_TRANSITION_LATENCY        20000
> > +#define AMD_PSTATE_TRANSITION_DELAY  1000
> 
> How were these values derived? If from documentation, it'll be good to add a
> link to the relevant documentation. And if they were derived from testing,
> please mention this in the commit log (along with some details of the tests used
> to determine the value).

The values are calculated from the CPU PM firmware and hardware design.
There are some latency and delay values defined  in the PM firmware, I have no documents about the detail for now. 

Perry.
> 
> >
> >  /*
> >   * TODO: We need more time to fine tune processors with shared memory
> > solution
Re: [PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency transition delay time
Posted by Punit Agrawal 3 years, 7 months ago
Hi Perry,

"Yuan, Perry" <Perry.Yuan@amd.com> writes:

> [AMD Official Use Only - General]
>
> Hi Punit
>
>> -----Original Message-----
>> From: Punit Agrawal <punit.agrawal@bytedance.com>
>> Sent: Monday, August 15, 2022 11:06 PM
>> To: Yuan, Perry <Perry.Yuan@amd.com>
>> Cc: rafael.j.wysocki@intel.com; Huang, Ray <Ray.Huang@amd.com>;
>> viresh.kumar@linaro.org; Sharma, Deepak <Deepak.Sharma@amd.com>;
>> Limonciello, Mario <Mario.Limonciello@amd.com>; Fontenot, Nathan
>> <Nathan.Fontenot@amd.com>; Deucher, Alexander
>> <Alexander.Deucher@amd.com>; Su, Jinzhou (Joe) <Jinzhou.Su@amd.com>;
>> Huang, Shimmer <Shimmer.Huang@amd.com>; Du, Xiaojian
>> <Xiaojian.Du@amd.com>; Meng, Li (Jassmine) <Li.Meng@amd.com>; linux-
>> pm@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v5 6/7] cpufreq: amd-pstate: update pstate frequency
>> transition delay time
>> 
>> [CAUTION: External Email]
>> 
>> Perry Yuan <Perry.Yuan@amd.com> writes:
>> 
>> > Change the default transition latency to be 20ms that is more
>> > reasonable transition delay for AMD processors in non-EPP driver mode.
>> >
>> > Update transition delay time to 1ms, in the AMD CPU autonomous mode
>> > and non-autonomous mode, CPPC firmware will decide frequency at 1ms
>> > timescale based on the workload utilization.
>> >
>> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> > Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
>> > ---
>> >  drivers/cpufreq/amd-pstate.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/cpufreq/amd-pstate.c
>> > b/drivers/cpufreq/amd-pstate.c index e40177d14310..9cb051d61422 100644
>> > --- a/drivers/cpufreq/amd-pstate.c
>> > +++ b/drivers/cpufreq/amd-pstate.c
>> > @@ -41,8 +41,8 @@
>> >  #include <asm/msr.h>
>> >  #include "amd-pstate-trace.h"
>> >
>> > -#define AMD_PSTATE_TRANSITION_LATENCY        0x20000
>> > -#define AMD_PSTATE_TRANSITION_DELAY  500
>> > +#define AMD_PSTATE_TRANSITION_LATENCY        20000
>> > +#define AMD_PSTATE_TRANSITION_DELAY  1000
>> 
>> How were these values derived? If from documentation, it'll be good to add a
>> link to the relevant documentation. And if they were derived from testing,
>> please mention this in the commit log (along with some details of the tests used
>> to determine the value).
>
> The values are calculated from the CPU PM firmware and hardware design.
> There are some latency and delay values defined  in the PM firmware, I have no documents about the detail for now. 

In that case, please mention that the values are calculated from
firmware / hardware design in the commit log (and include a reference to
the firmware sources if available).

Thanks!

[...]