From: Peter Zijlstra <peterz@infradead.org>
To: Joel Fernandes <joelaf@google.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Len Brown <lenb@kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v2 1/2] cpufreq: Make iowait boost a policy option
Date: Fri, 19 May 2017 11:42:45 +0200 [thread overview]
Message-ID: <20170519094245.ztm6tt2iwkaiwsya@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20170519062344.27692-2-joelaf@google.com>
On Thu, May 18, 2017 at 11:23:43PM -0700, Joel Fernandes wrote:
> Make iowait boost a cpufreq policy option and enable it for intel_pstate
> cpufreq driver. Governors like schedutil can use it to determine if
> boosting for tasks that wake up with p->in_iowait set is needed.
Rather than just flat out disabling the option, is there something
better we can do on ARM?
The reason for the IO-wait boost is to ensure we feed our external
devices data ASAP, this reduces wait times, increases throughput and
decreases the duration the devices have to operate.
I realize max freq/volt might not be the best option for you, but is
there another spot that would make sense? I can imagine you want to
return your MMC to low power state ASAP as well.
So rather than a disable flag, I would really rather see an IO-wait OPP
state selector or something.
next prev parent reply other threads:[~2017-05-19 9:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 6:23 [PATCH v2 0/2] Make iowait_boost optional and default to policy Joel Fernandes
2017-05-19 6:23 ` [PATCH v2 1/2] cpufreq: Make iowait boost a policy option Joel Fernandes
2017-05-19 9:42 ` Peter Zijlstra [this message]
2017-05-19 10:21 ` Peter Zijlstra
2017-05-19 17:04 ` Joel Fernandes
2017-05-22 8:21 ` Peter Zijlstra
2017-05-24 20:17 ` Joel Fernandes
2017-06-10 8:08 ` Joel Fernandes
2017-06-10 13:56 ` Peter Zijlstra
2017-06-11 6:59 ` Joel Fernandes
2017-05-19 6:23 ` [PATCH v2 2/2] sched: Make iowait_boost optional in schedutil Joel Fernandes
2017-05-19 6:50 ` Viresh Kumar
2017-05-19 16:10 ` Joel Fernandes
2017-07-11 19:02 ` Saravana Kannan
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=20170519094245.ztm6tt2iwkaiwsya@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=joelaf@google.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--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.