From: Steve Muckle <steve.muckle@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Steve Muckle <steve.muckle@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Juri Lelli <Juri.Lelli@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Michael Turquette <mturquette@baylibre.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged
Date: Thu, 19 May 2016 16:34:08 -0700 [thread overview]
Message-ID: <20160519233408.GC15383@graphite.smuckle.net> (raw)
In-Reply-To: <CAJZ5v0gF07sox1+84eLeYPK6Ksj26s7iKU6zc=+pMOQimwUYog@mail.gmail.com>
On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote:
> But anyway this change again seems to be an optimization that might be
> done later to me.
>
> I guess there are many things that might be optimized in schedutil,
> but I'd prefer to address one item at a time, maybe going after the
> ones that appear most relevant first?
Calling the last two patches in this series optimizations is a stretch
IMO. Issuing frequency change requests that result in the same
target-supported frequency is clearly unnecessary and ends up delaying
more urgent frequency changes, which I think is more like a bug. These
patches are also needed in conjunction with the first three to address
the remote wakeup delay.
Are there specific items you want to see addressed before these patches
could go in? I'm aware of the RT/DL support that needs improving, though
that should be orthogonal.
Also if it helps, I can provide a test case and/or traces to show the
need for the last two patches.
thanks,
Steve
next prev parent reply other threads:[~2016-05-19 23:34 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 21:20 [PATCH 0/5] cpufreq: schedutil: improve latency of response Steve Muckle
2016-05-09 21:20 ` [PATCH 1/5] sched: cpufreq: add cpu to update_util_data Steve Muckle
2016-05-18 23:13 ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs Steve Muckle
2016-05-18 23:24 ` Rafael J. Wysocki
2016-05-19 18:40 ` Steve Muckle
2016-05-19 20:55 ` Rafael J. Wysocki
2016-05-19 22:59 ` Steve Muckle
2016-05-19 23:14 ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 3/5] sched: cpufreq: call cpufreq hook from " Steve Muckle
2016-05-18 23:33 ` Rafael J. Wysocki
2016-05-19 12:00 ` Rafael J. Wysocki
2016-05-19 19:19 ` Steve Muckle
2016-05-19 21:06 ` Rafael J. Wysocki
2016-05-19 23:04 ` Steve Muckle
2016-05-21 19:46 ` Steve Muckle
2016-06-01 20:09 ` Steve Muckle
2016-05-09 21:20 ` [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency Steve Muckle
2016-05-18 23:37 ` Rafael J. Wysocki
2016-05-19 19:35 ` Steve Muckle
2016-05-19 21:07 ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged Steve Muckle
2016-05-18 23:44 ` Rafael J. Wysocki
2016-05-19 19:46 ` Steve Muckle
2016-05-19 21:15 ` Rafael J. Wysocki
2016-05-19 23:34 ` Steve Muckle [this message]
2016-05-20 0:24 ` Rafael J. Wysocki
2016-05-20 0:37 ` Rafael J. Wysocki
2016-05-20 0:40 ` Steve Muckle
2016-05-20 0:46 ` Rafael J. Wysocki
2016-05-20 11:39 ` Rafael J. Wysocki
2016-05-20 11:54 ` Rafael J. Wysocki
2016-05-20 11:59 ` Rafael J. Wysocki
2016-05-20 0:37 ` Steve Muckle
2016-05-20 0:55 ` 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=20160519233408.GC15383@graphite.smuckle.net \
--to=steve.muckle@linaro.org \
--cc=Juri.Lelli@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=mturquette@baylibre.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--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