All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stratos Karafotis <stratosk@semaphore.gr>
To: Dirk Brandewie <dirk.j.brandewie@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: [query] cpufreq: intel_pstate: diverge of current_pstate and actual P state
Date: Wed, 21 May 2014 00:11:04 +0300	[thread overview]
Message-ID: <537BC4E8.60500@semaphore.gr> (raw)

Hi all,

Currently, we use the current P state to calculate the busy_scaled factor
and then the next P state.

We also read the MSR_TURBO_RATIO_LIMIT to get the turbo ratio limit as the
turbo_pstate. But, we always read bits 7:0 ("Maximum turbo ratio limit of 1
core active").

So, in processor families that have different turbo ratio limit
depending on active cores the current P state as it's considered
by the driver might be different from the actual current P state.

For example, I use an i7-3770 which reports as maximum turbo ratio limits
with 1/2/3/4 actives cores the values 39/39/38/37. So, in some cases
we will calculate as the next P state the value 39. If the active cores
at that time was 3 or 4 the actual P state will be 38 or 37.
The current_pstate variable will have the value 39 and this will lead
to wrong calculation at the next sampling interval.

Trying to find a solution to the above I couldn't find an MSR that
we could use to get the number of active cores and use the respective
turbo ratio limit.

I also thought to use the IA32_PERF_STATUS to get the current P state
and use it in the calculations, but its scope is per core and not per
thread.

Am I missing something? If the above is correct, any idea how this
could be resolved?


Thanks in advance,
Stratos


             reply	other threads:[~2014-05-20 21:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 21:11 Stratos Karafotis [this message]
2014-05-20 21:31 ` [query] cpufreq: intel_pstate: diverge of current_pstate and actual P state Dirk Brandewie
2014-05-20 21:59   ` Stratos Karafotis
2014-05-20 23:01     ` Dirk Brandewie
2014-05-21 17:22       ` Stratos Karafotis

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=537BC4E8.60500@semaphore.gr \
    --to=stratosk@semaphore.gr \
    --cc=dirk.j.brandewie@intel.com \
    --cc=linux-pm@vger.kernel.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.