From: Juri Lelli <juri.lelli@redhat.com>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: peterz@infradead.org, mingo@redhat.com, rjw@rjwysocki.net,
viresh.kumar@linaro.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, tglx@linutronix.de,
vincent.guittot@linaro.org, rostedt@goodmis.org,
luca.abeni@santannapisa.it, claudio@evidence.eu.com,
tommaso.cucinotta@santannapisa.it, bristot@redhat.com,
mathieu.poirier@linaro.org, tkjos@android.com, joelaf@google.com,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
alessio.balsini@arm.com, Juri Lelli <juri.lelli@arm.com>,
Ingo Molnar <mingo@kernel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
Date: Tue, 5 Dec 2017 13:34:00 +0100 [thread overview]
Message-ID: <20171205123400.GA15085@localhost.localdomain> (raw)
In-Reply-To: <20171205115509.GK31247@e110439-lin>
Hi,
On 05/12/17 11:55, Patrick Bellasi wrote:
> Hi Juri,
>
> On 04-Dec 11:23, Juri Lelli wrote:
> [...]
>
> > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> > index de1ad1fffbdc..c22457868ee6 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -475,7 +475,20 @@ static void sugov_policy_free(struct sugov_policy *sg_policy)
> > static int sugov_kthread_create(struct sugov_policy *sg_policy)
> > {
> > struct task_struct *thread;
> > - struct sched_param param = { .sched_priority = MAX_USER_RT_PRIO / 2 };
> > + struct sched_attr attr = {
> > + .size = sizeof(struct sched_attr),
> > + .sched_policy = SCHED_DEADLINE,
> > + .sched_flags = SCHED_FLAG_SUGOV,
> > + .sched_nice = 0,
> > + .sched_priority = 0,
> > + /*
> > + * Fake (unused) bandwidth; workaround to "fix"
> > + * priority inheritance.
> > + */
> > + .sched_runtime = 1000000,
> > + .sched_deadline = 10000000,
> > + .sched_period = 10000000,
>
> Why not assigning a minimal (but yet CBS accounted) bandwidth to
> this DL task?
>
> I understand that it should be a minimal task which bandwidth
> requirement is likely into the "noise".
> Is there any other more specific reason?
>
At least two, IMHO.
1. Throttling: assigning any sort of bandwidth is difficult (every
platform is different), and if that is too small the task responsible
for changing frequency might be throttled and delayed; if too big you
are wasting resources.
2. Affinity: some platform affine these kthreads to related_cpus; and it
is something you might want to do to save power anyway. Problem with DL
is that (at least currently) you are not free to change a task's
affinity mask without creating an exclusive cpuset.
[...]
> > +static inline
> > +void add_rq_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
> > +{
> > + if (!(dl_se->flags & SCHED_FLAG_SUGOV))
> > + __add_rq_bw(dl_se->dl_bw, dl_rq);
>
> What about using for all these wrappers the same utility function you
> already use in this source file? I.e.
>
> if (unlikely(dl_entity_is_special(dl_se)))
> return;
> __add_rq_bw(dl_se->dl_bw, dl_rq);
Should work. I'll try to do the change.
[...]
> > @@ -2436,6 +2472,9 @@ int sched_dl_overflow(struct task_struct *p, int policy,
> > u64 new_bw = dl_policy(policy) ? to_ratio(period, runtime) : 0;
> > int cpus, err = -1;
> >
> > + if (attr->sched_flags & SCHED_FLAG_SUGOV)
> > + return 0;
> > +
>
> Same note on using:
>
> if (unlikely(dl_entity_is_special(dl_se)))
>
> here and in the next chunk too.
OK.
>
> > /* !deadline task may carry old deadline bandwidth */
> > if (new_bw == p->dl.dl_bw && task_has_dl_policy(p))
> > return 0;
> > @@ -2522,6 +2561,10 @@ void __getparam_dl(struct task_struct *p, struct sched_attr *attr)
> > */
> > bool __checkparam_dl(const struct sched_attr *attr)
> > {
> > + /* special dl tasks don't actually use any parameter */
> > + if (attr->sched_flags & SCHED_FLAG_SUGOV)
> > + return true;
> > +
> > /* deadline != 0 */
> > if (attr->sched_deadline == 0)
> > return false;
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index a1730e39cbc6..280b421a82e8 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -156,13 +156,33 @@ static inline int task_has_dl_policy(struct task_struct *p)
> > return dl_policy(p->policy);
> > }
> >
> > +/*
> > + * !! For sched_setattr_nocheck() (kernel) only !!
> > + *
> > + * This is actually gross. :(
> > + *
> > + * It is used to make schedutil kworker(s) higher priority than SCHED_DEADLINE
> > + * tasks, but still be able to sleep. We need this on platforms that cannot
> > + * atomically change clock frequency. Remove once fast switching will be
> > + * available on such platforms.
> > + *
> > + * SUGOV stands for SchedUtil GOVernor.
> > + */
> > +#define SCHED_FLAG_SUGOV 0x10000000
> > +
> > +static inline int dl_entity_is_special(struct sched_dl_entity *dl_se)
>
> This should better return a bool...
>
>
> > +{
>
> ... and maybe it can optimize some builds via constants propagations to add:
>
> #ifdef CONFIG_CPU_FREQ_GOV_SCHEDUTIL
> > + return dl_se->flags & SCHED_FLAG_SUGOV;
> #else
> return false;
> #endif
Sure.
>
> > +}
> > +
> > /*
> > * Tells if entity @a should preempt entity @b.
> > */
> > static inline bool
> > dl_entity_preempt(struct sched_dl_entity *a, struct sched_dl_entity *b)
> > {
> > - return dl_time_before(a->deadline, b->deadline);
> > + return dl_entity_is_special(a) ||
> > + dl_time_before(a->deadline, b->deadline);
>
> Given that being special is less likely, perhaps better to have:
>
> return dl_time_before(a->deadline, b->deadline) ||
> dl_entity_is_special(a);
OK.
Thanks for the review!
Best,
- Juri
next prev parent reply other threads:[~2017-12-05 12:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 10:23 [RFC PATCH v2 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli
2017-12-05 15:09 ` Patrick Bellasi
2017-12-05 15:24 ` Juri Lelli
2017-12-05 16:34 ` Patrick Bellasi
2017-12-05 16:40 ` Juri Lelli
2017-12-20 12:51 ` Peter Zijlstra
2018-01-10 12:17 ` [tip:sched/core] sched/cpufreq: Use the " tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 2/8] sched/deadline: move cpu frequency selection triggering points Juri Lelli
2018-01-10 12:18 ` [tip:sched/core] sched/deadline: Move CPU " tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli
2017-12-05 11:55 ` Patrick Bellasi
2017-12-05 12:34 ` Juri Lelli [this message]
2017-12-20 12:57 ` Peter Zijlstra
2018-01-10 12:18 ` [tip:sched/core] sched/cpufreq: Change the worker kthread to SCHED_DEADLINE tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli
2017-12-05 15:17 ` Patrick Bellasi
2017-12-05 15:26 ` Juri Lelli
2018-01-10 12:19 ` [tip:sched/core] sched/cpufreq: Split " tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli
2018-01-10 12:19 ` [tip:sched/core] sched/cpufreq: Always " tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 6/8] sched/sched.h: remove sd arch_scale_freq_capacity parameter Juri Lelli
2018-01-10 12:19 ` [tip:sched/core] sched/cpufreq: Remove arch_scale_freq_capacity()'s 'sd' parameter tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Juri Lelli
2018-01-10 12:20 ` [tip:sched/core] sched/cpufreq: Move arch_scale_{freq,cpu}_capacity() outside of #ifdef CONFIG_SMP tip-bot for Juri Lelli
2017-12-04 10:23 ` [RFC PATCH v2 8/8] sched/deadline: make bandwidth enforcement scale-invariant Juri Lelli
2018-01-10 12:20 ` [tip:sched/core] sched/deadline: Make " tip-bot for Juri Lelli
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=20171205123400.GA15085@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=alessio.balsini@arm.com \
--cc=bristot@redhat.com \
--cc=claudio@evidence.eu.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tkjos@android.com \
--cc=tommaso.cucinotta@santannapisa.it \
--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 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.