From: Yuyang Du <yuyang.du@intel.com>
To: Doug Smythies <dsmythies@telus.net>
Cc: 'Johan Hovold' <jhovold@gmail.com>,
'Dirk Brandewie' <dirk.brandewie@gmail.com>,
'Viresh Kumar' <viresh.kumar@linaro.org>,
dirk.j.brandewie@intel.com,
"'Rafael J. Wysocki'" <rafael.j.wysocki@intel.com>,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
'Linux Kernel Mailing List' <linux-kernel@vger.kernel.org>,
'Greg Kroah-Hartman' <gregkh@linuxfoundation.org>,
'Stratos Karafotis' <stratosk@semaphore.gr>
Subject: Re: Performance regression in v3.14
Date: Thu, 29 May 2014 00:53:38 +0800 [thread overview]
Message-ID: <20140528165337.GB2296@intel.com> (raw)
In-Reply-To: <002401cf7a8d$fc6d9090$f548b1b0$@net>
> That is not true. Yes, and due to the setpoint being less than
> 100, which is needed or the driver won't work at all, there is
> a tendency to drive the target pstate upwards.
> However that is tempered by both the PID proportional gain,
> and ultimately integer math. More importantly, the CPU
> itself tells the driver when it is operating below the target
> pstate and driver responds.
>
> Additionally, the tendency to drive up the target pstate
> too much is exasperated by some extra rounding up at a
> couple of spots. Dirk has a pending fix.
>
> > And a few iterations
> > later, we will reach max (possible) frequency,
> > then we are effectively performance governor
> > (highest frequency all the time).
>
> Please do not confuse highest target pstate with
> highest frequency. They are not the same. The processor
> itself can back off.
>
Hi Doug,
All you said is about the hardware will not give whatever software wants
(e.g., requested freq too high). Agreed.
But does it matter to this discussion?
Yuyang
next prev parent reply other threads:[~2014-05-28 16:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 16:35 Performance regression in v3.14 Johan Hovold
2014-05-07 5:40 ` Viresh Kumar
2014-05-07 7:35 ` Johan Hovold
2014-05-07 8:36 ` Romain Francoise
2014-05-07 14:10 ` Dirk Brandewie
2014-05-21 9:00 ` Johan Hovold
2014-05-28 7:59 ` Johan Hovold
2014-05-28 0:35 ` Yuyang Du
2014-05-28 16:00 ` Doug Smythies
2014-05-28 16:53 ` Yuyang Du [this message]
2014-05-30 2:27 ` Greg Kroah-Hartman
2014-05-30 8:49 ` Johan Hovold
2014-05-30 12:29 ` Rafael J. Wysocki
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=20140528165337.GB2296@intel.com \
--to=yuyang.du@intel.com \
--cc=cpufreq@vger.kernel.org \
--cc=dirk.brandewie@gmail.com \
--cc=dirk.j.brandewie@intel.com \
--cc=dsmythies@telus.net \
--cc=gregkh@linuxfoundation.org \
--cc=jhovold@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=stratosk@semaphore.gr \
--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 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).