From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Juri Lelli <juri.lelli@arm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux PM <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Joel Fernandes <joelaf@google.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation
Date: Tue, 11 Apr 2017 23:03:51 +0200 [thread overview]
Message-ID: <CAJZ5v0iApX_LBCr--kOV0LzJyy-LhgYLaNV9hER8zXeF0R3F=Q@mail.gmail.com> (raw)
In-Reply-To: <20170411070044.GK30804@e106622-lin>
On Tue, Apr 11, 2017 at 9:00 AM, Juri Lelli <juri.lelli@arm.com> wrote:
> On 10/04/17 23:13, Rafael J. Wysocki wrote:
>> On Mon, Apr 10, 2017 at 1:26 PM, Juri Lelli <juri.lelli@arm.com> wrote:
>
> [...]
>
>> > Given that for RT (and still for DL as well) the next event is a
>> > periodic tick, couldn't happen that the required frequency transition
>> > for an RT task, that unfortunately woke up before the end of a throttling
>> > period, gets delayed of a tick interval (at least 4ms on ARM)?
>>
>> No, that won't be an entire tick unless it wakes up exactly at the
>> update time AFAICS.
>>
>
> Right. I was trying to think about worst case, as I'm considering RT
> type of tasks.
>
>> > Don't we need to treat such wake up events (RT/DL) in a special way and
>> > maybe set a timer to fire and process them as soon as the current
>> > throttling period elapses? Might be a patch on top of this I guess.
>>
>> Setting a timer won't be a good idea at all, as it would need to be a
>> deferrable one and Thomas would not like that (I'm sure).
>>
>
> Why deferrable? IMHO, we should be servicing RT requestes as soon as the
> HW is capable of. Even a small delay of, say, a couple of ms could be
> causing deadline misses.
If it is not deferrable, it will wake up the CPU from idle, but that's
not a concern here, because we're assuming that the CPU is not idle
anyway, so fair enough.
>> We could in principle add some special casing around that, like for
>> example pass flags to sugov_should_update_freq() and opportunistically
>> ignore freq_update_delay_ns if SCHED_CPUFREQ_RT_DL is set in there,
>> but that would lead to extra overhead on systems where frequency
>> updates happen in-context.
>>
>
> Also, it looks still event driven to me. If the RT task is the only
> thing running, nothing will trigger a potential frequency change
> re-evaluation before the next tick.
If freq_update_delay_ns is opportunistically ignored for
SCHED_CPUFREQ_RT_DL set in the flags by sugov_should_update_freq(),
then all of the updates with that flag set will cause a frequency
update to happen immediately *except* *for* the ones that require us
to wait for work_in_progress to become false, but in that case the
kthread might trigger an update (eg. by scheduling an irq_work) after
it has cleared work_in_progress.
No timers needed I guess after all? :-)
>> Also the case looks somewhat corner to me to be honest.
>>
>
> Sure. Only thinking about potential problems here. However, playing with
> my DL patches I noticed that this can be actually a problem, as for DL,
> for example, we trigger a frequency switch when the task wakes up, but
> then we don't do anything during the tick (because it doesn't seem to
> make sense to do anything :). So, if we missed the opportunity to
> increase frequency at enqueue time, the task is hopelessly done. :(
>
> Anyway, since this looks anyway something that we might want on top of
> your patches, I'll play with the idea when refreshing my set and see
> what I get.
Sounds good.
Thanks,
Rafael
prev parent reply other threads:[~2017-04-11 21:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 0:07 [RFC/RFT][PATCH 0/2] cpufreq: schedutil: Updates related to the rate limit Rafael J. Wysocki
2017-04-10 0:10 ` [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent latency multupliers Rafael J. Wysocki
2017-04-10 10:38 ` Brendan Jackman
2017-04-10 11:03 ` Rafael J. Wysocki
2017-04-10 22:20 ` [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent transition delays Rafael J. Wysocki
2017-04-11 11:14 ` Viresh Kumar
2017-04-11 14:01 ` Rafael J. Wysocki
2017-04-14 22:51 ` Rafael J. Wysocki
2017-04-15 2:23 ` Joel Fernandes
2017-04-18 9:43 ` Brendan Jackman
2017-04-17 5:41 ` Viresh Kumar
2017-04-10 0:11 ` [RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation Rafael J. Wysocki
2017-04-10 6:39 ` Joel Fernandes
2017-04-10 20:59 ` Rafael J. Wysocki
2017-04-11 1:57 ` Joel Fernandes
2017-04-11 20:53 ` Rafael J. Wysocki
2017-04-10 11:26 ` Juri Lelli
2017-04-10 21:13 ` Rafael J. Wysocki
2017-04-11 7:00 ` Juri Lelli
2017-04-11 21:03 ` 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='CAJZ5v0iApX_LBCr--kOV0LzJyy-LhgYLaNV9hER8zXeF0R3F=Q@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=joelaf@google.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--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).