From: "Doug Smythies" <dsmythies@telus.net>
To: 'Srinivas Pandruvada' <srinivas.pandruvada@linux.intel.com>
Cc: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
'Philippe Longepe' <philippe.longepe@linux.intel.com>,
linux-pm@vger.kernel.org, 'Len Brown' <len.brown@intel.com>,
"'Rafael J. Wysocki'" <rafael@kernel.org>,
'Stephane Gasparini' <stephane.gasparini@linux.intel.com>
Subject: RE: [PATCH V4] intel_pstate: Use avg_pstate instead of current_pstate
Date: Fri, 22 Apr 2016 08:18:49 -0700 [thread overview]
Message-ID: <004701d19caa$4644c360$d2ce4a20$@net> (raw)
In-Reply-To: <CAJZ5v0hMTanSQQ9VX2YbTgRvtUkkTDJAJSYcHGxAdtm=xEHE6g@mail.gmail.com>
Srinivas,
Recall a couple of months ago, on the "Increase hold-off time before busyness is scaled"
thread, Stephane suggested we try applying this method on the get_target_pstate_use_performance
branch of the intel_pstate driver, as opposed to just on the get_target_pstate_use_cpu_load branch.
It didn't make any difference with respect to the hold-off time issue.
However, I did spend considerable time testing it in other scenarios.
It does somewhat temper the occasional tendency to suddenly have a ridiculously high
scaled busy number with virtually no load (the same issue from the
"[intel-pstate driver regression] processor frequency very high even if in idle" thread,
that continued in https://bugzilla.kernel.org/show_bug.cgi?id=115771 )
I didn't find any significant regression, and did observe some small energy savings
in some scenarios (admittedly, small enough to have possibly been simply test to test
variations, and I didn't do enough tests to extract a definite trend).
I am suggesting to consider extending the patch to get_target_pstate_use_performance also.
... Doug
next prev parent reply other threads:[~2016-04-22 15:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 7:23 [PATCH V4] intel_pstate: Use avg_pstate instead of current_pstate Philippe Longepe
2016-04-04 7:23 ` Philippe Longepe
2016-04-22 0:48 ` Rafael J. Wysocki
2016-04-22 0:59 ` Srinivas Pandruvada
2016-04-22 1:01 ` Rafael J. Wysocki
2016-04-22 15:18 ` Doug Smythies [this message]
2016-04-22 16:26 ` Srinivas Pandruvada
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='004701d19caa$4644c360$d2ce4a20$@net' \
--to=dsmythies@telus.net \
--cc=len.brown@intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=philippe.longepe@linux.intel.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stephane.gasparini@linux.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.