From: Luca Abeni <luca.abeni@santannapisa.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@arm.com>,
Claudio Scordino <claudio@evidence.eu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Joel Fernandes <joelaf@google.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization
Date: Mon, 27 Mar 2017 16:56:51 +0200 [thread overview]
Message-ID: <20170327165651.2d09b00d@luca> (raw)
In-Reply-To: <20170327142633.nubm5saddpitylot@hirez.programming.kicks-ass.net>
On Mon, 27 Mar 2017 16:26:33 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Mar 24, 2017 at 04:53:01AM +0100, luca abeni wrote:
> > From: Luca Abeni <luca.abeni@santannapisa.it>
> >
> > Instead of decreasing the runtime as "dq = -Uact dt" (eventually
> > divided by the maximum utilization available for deadline tasks),
> > decrease it as "dq = -(1 - Uinact) dt", where Uinact is the
> > "inactive utilization".
>
> > In this way, the maximum fraction of CPU time that can be reclaimed
> > is given by the total utilization of deadline tasks.
> > This approach solves some fairness issues that have been noticed
> > with "traditional" global GRUB reclaiming.
>
> I think the Changelog could do with explicit enumeration of what
> "some" is.
Sorry, when writing the changelog I've been lazy; I'll add a link to
Daniel's email showing the problem in action.
> > Signed-off-by: Luca Abeni <luca.abeni@santannapisa.it>
> > Tested-by: Daniel Bristot de Oliveira <bristot@redhat.com>
> > ---
> > kernel/sched/deadline.c | 23 ++++++++++++++++-------
> > 1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index d70a7b9..c393c3d 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -900,14 +900,23 @@ extern bool sched_rt_bandwidth_account(struct
> > rt_rq *rt_rq); /*
> > * This function implements the GRUB accounting rule:
> > * according to the GRUB reclaiming algorithm, the runtime is
> > + * not decreased as "dq = -dt", but as "dq = (1 - Uinact) dt",
> > where
>
> Changelog had it right I think: dq = -(1 - Uinact) dt
Sorry about the typo... I'll fix it
> > + * Uinact is the (per-runqueue) inactive utilization, computed as
> > the
> > + * difference between the "total runqueue utilization" and the
> > runqueue
> > + * active utilization.
> > + * Since rq->dl.running_bw and rq->dl.this_bw contain utilizations
> > + * multiplied by 2^20, the result has to be shifted right by 20.
> > */
> > -u64 grub_reclaim(u64 delta, struct rq *rq)
> > +u64 grub_reclaim(u64 delta, struct rq *rq, u64 u)
> > {
> > + u64 u_act;
> > +
> > + if (rq->dl.this_bw - rq->dl.running_bw > (1 << 20) - u)
> > + u_act = u;
> > + else
> > + u_act = (1 << 20) - rq->dl.this_bw +
> > rq->dl.running_bw; +
> > + return (delta * u_act) >> 20;
>
> But that's not what is done here I think, something like this instead:
>
> Uinact = Utot - Uact
>
> -t_u dt ; Uinact > (1 - t_u)
> dq = {
> -(1 - Uinact) dt
>
>
> And nowhere do we have an explanation for that.
Sorry about this confusion... The accounting should be
dq = -(1 - Uinact)dt
but if (1 - Uinact) is too large (larger than the task's utilization)
then we use the task's utilization instead (otherwise, we end up
reclaiming other runqueues' time). I realized that this check was
needed after writing the comments, and I forgot to update the comments
when I fixed the code :(
> Now, I suspect we can write that like: dq = -max{ t_u, (1 - Uinact) }
> dt, which would suggest this is a sanity check on Utot, which I
> suspect can be over 1. Is this what is happening?
Right... I'll fix the code and comments according to your suggestion.
Thanks,
Luca
> #define BW_SHIFT 20
> #define BW_UNIT (1 << BW_SHIFT)
>
> static inline
> u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity
> *dl_se) {
> u64 u_inact = rq->dl.this_bw - rq->dl.running_bw; /* Utot -
> Uact */ u64 u_act;
>
> /*
> * What we want to write is:
> *
> * max(BW_UNIT - u_inact, dl_se->dl_bw)
> *
> * but we cannot do that since Utot can be larger than 1,
> * which means u_inact can be larger than 1, which would
> * have the above result in negative values.
> */
> if (u_inact > (BW_UNIT - dl_se->dl_bw))
> u_act = dl_se->dl_bw;
> else
> u_act = BW_UNIT - u_inact;
>
> return (delta * u_act) >> BW_SHIFT;
> }
>
> Hmm?
next prev parent reply other threads:[~2017-03-27 14:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 3:52 [RFC v5 0/9] CPU reclaiming for SCHED_DEADLINE luca abeni
2017-03-24 3:52 ` [RFC v5 1/9] sched/deadline: track the active utilization luca abeni
2017-03-26 17:04 ` Mathieu Poirier
2017-03-26 20:55 ` luca abeni
2017-03-24 3:52 ` [RFC v5 2/9] sched/deadline: improve the tracking of " luca abeni
2017-03-24 13:20 ` Peter Zijlstra
2017-03-24 21:47 ` luca abeni
2017-03-25 2:31 ` Steven Rostedt
2017-03-27 8:20 ` Luca Abeni
2017-03-27 8:54 ` Claudio Scordino
2017-03-27 7:17 ` Juri Lelli
2017-03-27 7:43 ` Luca Abeni
2017-03-27 8:45 ` Juri Lelli
2017-03-27 7:36 ` Luca Abeni
2017-07-24 8:06 ` Luca Abeni
2017-07-24 9:04 ` Peter Zijlstra
2017-07-25 6:41 ` Luca Abeni
2017-03-24 13:23 ` Peter Zijlstra
2017-07-24 7:54 ` Luca Abeni
2017-07-24 9:11 ` Peter Zijlstra
2017-07-25 6:46 ` Luca Abeni
2017-03-26 17:32 ` Mathieu Poirier
2017-03-26 21:01 ` luca abeni
2017-03-24 3:52 ` [RFC v5 3/9] sched/deadline: fix the update of the total -deadline utilization luca abeni
2017-03-24 3:52 ` [RFC v5 4/9] sched/deadline: implement GRUB accounting luca abeni
2017-03-24 3:52 ` [RFC v5 5/9] sched/deadline: do not reclaim the whole CPU bandwidth luca abeni
2017-03-24 14:00 ` Peter Zijlstra
2017-03-24 21:58 ` luca abeni
2017-03-25 2:38 ` Steven Rostedt
2017-03-27 8:35 ` Peter Zijlstra
2017-03-24 3:52 ` [RFC v5 6/9] sched/deadline: make GRUB a task's flag luca abeni
2017-03-24 3:53 ` [RFC v5 7/9] sched/deadline: track the "total rq utilization" too luca abeni
2017-03-24 3:53 ` [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization luca abeni
2017-03-27 14:26 ` Peter Zijlstra
2017-03-27 14:56 ` Luca Abeni [this message]
2017-03-27 15:53 ` Peter Zijlstra
2017-03-27 17:02 ` luca abeni
2017-05-08 7:41 ` Luca Abeni
2017-05-08 8:06 ` Peter Zijlstra
2017-05-09 9:37 ` Luca Abeni
2017-03-24 3:53 ` [RFC v5 9/9] sched/deadline: also reclaim bandwidth not used by dl tasks luca abeni
2017-03-27 14:03 ` Peter Zijlstra
2017-03-27 14:48 ` Luca Abeni
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=20170327165651.2d09b00d@luca \
--to=luca.abeni@santannapisa.it \
--cc=bristot@redhat.com \
--cc=claudio@evidence.eu.com \
--cc=joelaf@google.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tommaso.cucinotta@sssup.it \
/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.