From: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
To: Balbir Singh <bsingharora@gmail.com>,
rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Cc: ego@linux.vnet.ibm.com
Subject: Re: [PATCH 2/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate
Date: Thu, 14 Apr 2016 21:24:36 +0530 [thread overview]
Message-ID: <570FBD3C.2050505@linux.vnet.ibm.com> (raw)
In-Reply-To: <570F2D65.3090502@gmail.com>
Hi Balbir,
On 04/14/2016 11:10 AM, Balbir Singh wrote:
> On 13/04/16 04:06, Akshay Adiga wrote:
>> This patch brings down global pstate at a slower rate than the local
>> pstate. As the frequency transition latency from pmin to pmax is
>> observed to be in few millisecond granurality. It takes a performance
>> penalty during sudden frequency rampup. Hence by holding global pstates
>> higher than local pstate makes the subsequent rampups faster.
> What domains does local and global refer to?
The *global pstate* is a Chip-level entity as such, so the global entity
(Voltage) is managed across several cores. But with a DCM (Dual Chip Modules),
its more of a socket-level entity and hence Voltage is managed across both chips.
The *local pstate* is a Core-level entity, so the local entity (frequency) is
managed across threads.
I will include this in the commit message. Thanks.
>
>> +/*
>> + * Quadratic equation which gives the percentage rampdown for time elapsed in
>> + * milliseconds. time can be between 0 and MAX_RAMP_DOWN_TIME ( milliseconds )
>> + * This equation approximates to y = -4e-6 x^2
> Thanks for documenting this, but I think it will also be good to explain why we
> use y = -4 e-6*x^2 as opposed to any other magic numbers.
Well it empirically worked out best this way.
On an idle system we want the Global Pstate to ramp-down from max value to min over
a span of ~5 secs. Also we want initially ramp-down slowly and ramp-down rapidly later
on, hence the equation.
I will try to make this in the comment more informative.
Regards
Akshay Adiga
prev parent reply other threads:[~2016-04-14 15:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 18:06 [PATCH 0/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate Akshay Adiga
2016-04-12 18:06 ` [PATCH 1/2] cpufreq: powernv: Remove flag use-case of policy->driver_data Akshay Adiga
2016-04-12 18:06 ` [PATCH 2/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate Akshay Adiga
2016-04-13 5:03 ` Viresh Kumar
2016-04-13 17:57 ` Akshay Adiga
2016-04-13 17:57 ` Akshay Adiga
2016-04-14 2:19 ` Viresh Kumar
2016-04-14 5:40 ` Balbir Singh
2016-04-14 15:54 ` Akshay Adiga [this message]
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=570FBD3C.2050505@linux.vnet.ibm.com \
--to=akshay.adiga@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=ego@linux.vnet.ibm.com \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.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 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.