From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Benjamin Gaignard <benjamin.gaignard@st.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
hugues.fruchet@st.com, Mauro Carvalho Chehab <mchehab@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-media@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
LAK <linux-arm-kernel@lists.infradead.org>,
Patrick Bellasi <patrick.bellasi@arm.com>
Subject: Re: [RFC 0/3] Introduce cpufreq minimum load QoS
Date: Thu, 30 Apr 2020 11:00:05 +0200 [thread overview]
Message-ID: <CAJZ5v0g+9DYuGS8URoXYecOxcnu5-kC-D=gvYTuMvxMZbYXR9w@mail.gmail.com> (raw)
In-Reply-To: <CAKfTPtBNH8x=83RVQajgK859qQGjMTyvEdP4GioMONEZp9t-NA@mail.gmail.com>
On Wed, Apr 29, 2020 at 7:08 PM Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Wed, 29 Apr 2020 at 17:50, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
> > > When start streaming from the sensor the CPU load could remain very low
> > > because almost all the capture pipeline is done in hardware (i.e. without
> > > using the CPU) and let believe to cpufreq governor that it could use lower
> > > frequencies. If the governor decides to use a too low frequency that
> > > becomes a problem when we need to acknowledge the interrupt during the
> > > blanking time.
> > > The delay to ack the interrupt and perform all the other actions before
> > > the next frame is very short and doesn't allow to the cpufreq governor to
> > > provide the required burst of power. That led to drop the half of the frames.
> > >
> > > To avoid this problem, DCMI driver informs the cpufreq governors by adding
> > > a cpufreq minimum load QoS resquest.
> >
> > This seems to be addressing a use case that can be addressed with the help of
> > utilization clamps with less power overhead.
>
> Can't freq_qos_update_request() be also used if you don't have cgroup
> enabled on your system ?
It can.
The problem here is that imposing a global minimum frequency limit
generally causes the power draw of the system to increase regardless
of what is going on, including the CPUs that are not involved in the
handling of the interrupt in question.
That seems a bit excessive ...
prev parent reply other threads:[~2020-04-30 9:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 11:40 [RFC 0/3] Introduce cpufreq minimum load QoS Benjamin Gaignard
2020-04-24 11:40 ` [RFC 1/3] PM: QoS: " Benjamin Gaignard
2020-04-24 11:40 ` [RFC 2/3] cpufreq: governor: Use " Benjamin Gaignard
2020-04-24 11:40 ` [RFC 3/3] media: stm32-dcmi: Inform cpufreq governors about cpu load needs Benjamin Gaignard
2020-04-29 15:50 ` [RFC 0/3] Introduce cpufreq minimum load QoS Rafael J. Wysocki
2020-04-29 15:57 ` Benjamin GAIGNARD
2020-04-29 16:12 ` Valentin Schneider
2020-04-30 7:52 ` Benjamin GAIGNARD
2020-04-30 9:03 ` Rafael J. Wysocki
2020-04-30 13:46 ` Benjamin GAIGNARD
2020-04-30 14:33 ` Valentin Schneider
2020-04-30 15:37 ` Benjamin GAIGNARD
2020-04-30 15:50 ` Valentin Schneider
2020-05-04 9:17 ` Benjamin GAIGNARD
2020-05-20 7:29 ` [Linux-stm32] " Benjamin GAIGNARD
2020-04-29 17:08 ` Vincent Guittot
2020-04-30 9:00 ` Rafael J. Wysocki [this message]
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='CAJZ5v0g+9DYuGS8URoXYecOxcnu5-kC-D=gvYTuMvxMZbYXR9w@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@st.com \
--cc=hugues.fruchet@st.com \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=patrick.bellasi@arm.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--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;
as well as URLs for NNTP newsgroup(s).