| Message ID | 1519815970-5686-1-git-send-email-claudio@evidence.eu.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
Dear Rafael, dear Viresh, Il 28/02/2018 12:06, Claudio Scordino ha scritto: > When the SCHED_DEADLINE scheduling class increases the CPU utilization, > we should not wait for the rate limit, otherwise we may miss some > deadline. > > Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have > shown reductions of even 10% of deadline misses with a negligible > increase of energy consumption (measured through Baylibre Cape). As a follow up of the previous thread, I've put some figures here: https://gist.github.com/claudioscordino/d4a10e8b3ceac419fb0c8b552db19806 In some cases, I've noticed the patch to even reduce the energy consumption (due to a mix of factors plus DL tasks entering the inactive state sooner). I've also tried to create the "ramp-up" scenario by allocating 10 DL tasks on the same core, but it didn't produce any significant increase of consumption. IMHO, the overall behavior looks better. Best regards, Claudio
On Wed, Feb 28, 2018 at 12:06 PM, Claudio Scordino <claudio@evidence.eu.com> wrote: > When the SCHED_DEADLINE scheduling class increases the CPU utilization, > we should not wait for the rate limit, otherwise we may miss some > deadline. > > Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have > shown reductions of even 10% of deadline misses with a negligible > increase of energy consumption (measured through Baylibre Cape). > > Signed-off-by: Claudio Scordino <claudio@evidence.eu.com> > CC: Ingo Molnar <mingo@redhat.com> > CC: Patrick Bellasi <patrick.bellasi@arm.com> > CC: Dietmar Eggemann <dietmar.eggemann@arm.com> > CC: Morten Rasmussen <morten.rasmussen@arm.com> > CC: Juri Lelli <juri.lelli@redhat.com> > CC: Viresh Kumar <viresh.kumar@linaro.org> > CC: Vincent Guittot <vincent.guittot@linaro.org> > CC: Todd Kjos <tkjos@android.com> > CC: Joel Fernandes <joelaf@google.com> > CC: linux-pm@vger.kernel.org > CC: linux-kernel@vger.kernel.org > --- > Changes from v1: > - Logic moved from sugov_should_update_freq() to > sugov_update_single()/_shared() to not duplicate data structures > - Rate limit not ignored in case of "fast switch" I'm not sure about this last bit. IMO you can set sg_policy->need_freq_update even in the "fast switch" case to start with and special case it in the future if that turns out to be problematic. That is, unless you have data indicating that it already is problematic, of course. :-) > --- > kernel/sched/cpufreq_schedutil.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 7936f54..ca6ce72 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -273,6 +273,14 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, > sugov_set_iowait_boost(sg_cpu, time); > sg_cpu->last_update = time; > > + /* > + * Make sugov_should_update_freq() ignore the rate limit when DL > + * has increased the utilization. > + */ > + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && > + !(sg_policy->policy->fast_switch_enabled)) > + sg_policy->need_freq_update = true; > + > if (!sugov_should_update_freq(sg_policy, time)) > return; > > @@ -354,6 +362,14 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, > > raw_spin_lock(&sg_policy->update_lock); > > + /* > + * Make sugov_should_update_freq() ignore the rate limit when DL > + * has increased the utilization. > + */ > + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && > + !(sg_policy->policy->fast_switch_enabled)) > + sg_policy->need_freq_update = true; > + > sugov_get_util(sg_cpu); > sg_cpu->flags = flags; > > -- > 2.7.4 >
On 28-02-18, 12:22, Rafael J. Wysocki wrote: > On Wed, Feb 28, 2018 at 12:06 PM, Claudio Scordino > <claudio@evidence.eu.com> wrote: > > When the SCHED_DEADLINE scheduling class increases the CPU utilization, > > we should not wait for the rate limit, otherwise we may miss some > > deadline. > > > > Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have > > shown reductions of even 10% of deadline misses with a negligible > > increase of energy consumption (measured through Baylibre Cape). > > > > Signed-off-by: Claudio Scordino <claudio@evidence.eu.com> > > CC: Ingo Molnar <mingo@redhat.com> > > CC: Patrick Bellasi <patrick.bellasi@arm.com> > > CC: Dietmar Eggemann <dietmar.eggemann@arm.com> > > CC: Morten Rasmussen <morten.rasmussen@arm.com> > > CC: Juri Lelli <juri.lelli@redhat.com> > > CC: Viresh Kumar <viresh.kumar@linaro.org> > > CC: Vincent Guittot <vincent.guittot@linaro.org> > > CC: Todd Kjos <tkjos@android.com> > > CC: Joel Fernandes <joelaf@google.com> > > CC: linux-pm@vger.kernel.org > > CC: linux-kernel@vger.kernel.org > > --- > > Changes from v1: > > - Logic moved from sugov_should_update_freq() to > > sugov_update_single()/_shared() to not duplicate data structures > > - Rate limit not ignored in case of "fast switch" > > I'm not sure about this last bit. > > IMO you can set sg_policy->need_freq_update even in the "fast switch" > case to start with and special case it in the future if that turns out > to be problematic. That is, unless you have data indicating that it > already is problematic, of course. :-) > > > --- > > kernel/sched/cpufreq_schedutil.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > > index 7936f54..ca6ce72 100644 > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -273,6 +273,14 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, > > sugov_set_iowait_boost(sg_cpu, time); > > sg_cpu->last_update = time; > > > > + /* > > + * Make sugov_should_update_freq() ignore the rate limit when DL > > + * has increased the utilization. > > + */ > > + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && > > + !(sg_policy->policy->fast_switch_enabled)) > > + sg_policy->need_freq_update = true; > > + And a new routine for this block would be good as well.
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 7936f54..ca6ce72 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -273,6 +273,14 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, sugov_set_iowait_boost(sg_cpu, time); sg_cpu->last_update = time; + /* + * Make sugov_should_update_freq() ignore the rate limit when DL + * has increased the utilization. + */ + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && + !(sg_policy->policy->fast_switch_enabled)) + sg_policy->need_freq_update = true; + if (!sugov_should_update_freq(sg_policy, time)) return; @@ -354,6 +362,14 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, raw_spin_lock(&sg_policy->update_lock); + /* + * Make sugov_should_update_freq() ignore the rate limit when DL + * has increased the utilization. + */ + if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) && + !(sg_policy->policy->fast_switch_enabled)) + sg_policy->need_freq_update = true; + sugov_get_util(sg_cpu); sg_cpu->flags = flags;
When the SCHED_DEADLINE scheduling class increases the CPU utilization, we should not wait for the rate limit, otherwise we may miss some deadline. Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have shown reductions of even 10% of deadline misses with a negligible increase of energy consumption (measured through Baylibre Cape). Signed-off-by: Claudio Scordino <claudio@evidence.eu.com> CC: Ingo Molnar <mingo@redhat.com> CC: Patrick Bellasi <patrick.bellasi@arm.com> CC: Dietmar Eggemann <dietmar.eggemann@arm.com> CC: Morten Rasmussen <morten.rasmussen@arm.com> CC: Juri Lelli <juri.lelli@redhat.com> CC: Viresh Kumar <viresh.kumar@linaro.org> CC: Vincent Guittot <vincent.guittot@linaro.org> CC: Todd Kjos <tkjos@android.com> CC: Joel Fernandes <joelaf@google.com> CC: linux-pm@vger.kernel.org CC: linux-kernel@vger.kernel.org --- Changes from v1: - Logic moved from sugov_should_update_freq() to sugov_update_single()/_shared() to not duplicate data structures - Rate limit not ignored in case of "fast switch" --- kernel/sched/cpufreq_schedutil.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)