All of lore.kernel.org
 help / color / mirror / Atom feed
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 

  reply	other threads:[~2014-05-28 16:53 UTC|newest]

Thread overview: 15+ 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  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: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 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.