From: luca abeni <luca.abeni@unitn.it>
To: Juri Lelli <juri.lelli@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
peterz@infradead.org, linux-kernel@vger.kernel.org,
mingo@redhat.com
Subject: Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity
Date: Wed, 6 Jul 2016 10:44:11 +0200 [thread overview]
Message-ID: <20160706104411.0632d89f@utopia> (raw)
In-Reply-To: <20160705165829.GN17689@e106622-lin>
On Tue, 5 Jul 2016 17:58:30 +0100
Juri Lelli <juri.lelli@arm.com> wrote:
> On 05/07/16 12:47, Steven Rostedt wrote:
> > On Tue, 5 Jul 2016 15:39:33 +0100
> > Juri Lelli <juri.lelli@arm.com> wrote:
> >
> > return;
> > > > >
> > > > > /*
> > > > > + * Use the scheduling parameters of the top
> > > > > pi-waiter task,
> > > > > + * if we have one from which we can inherit a
> > > > > deadline.
> > > > > + */
> > > > > + if (pi_task && dl_se->dl_boosted &&
> > > > > dl_prio(pi_task->normal_prio))
> > > > > + pi_se = &pi_task->dl;
> > > > > +
> > > >
> > > > OK, I'm micro-optimizing now, but hey, isn't this a fast path?
> > > >
> > > > What about changing the above to:
> > > >
> > > > struct task_struct *pi_task;
> > > > [...]
> > > >
> > > > if (dl_se->dl_boosted && dl_prio(pi_task->normal_prio
> > > > &&
> > > ^
> > > OK, we need to reorder these two
> > > V
> > > > (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se)))
> > > > pe_se = &pi_task->dl;
> >
> > Opps, you're right.
> >
> > > >
> > > > This way we don't need to do any work of looking at
> > > > rt_mutex_get_top_task() for the normal case.
> > > >
> > >
> > > But, yes. Looks good to me. I'll shoot a v3 ASAP.
> >
> > I have to ask, should there be any check if the dl_se has a shorter
> > deadline than the pi one?
> >
>
> Yeah. I wondered the same actually. I convinced myself that, since the
> task is boosted, we assume that the donor will have a shorter
> deadline.
Do you mean relative deadline (dl_se->dl_deadline) or absolute
(scheduling) dealine (dl_se->deadline)?
If I understand well, here we are in setup_new_dl_entity(), right?
This should be called only from switched_to_dl(); so, dl_se is from a
task that is switching to -deadline. If it is dl_boosted, it means that
it is switching from SCHED_OTHER (or RT) to -deadline because of
inheritance... So, it is very likely that dl_se->dl_deadline is not
meaningful.
Moreover, setup_new_dl_entity() is only called if the current
scheduling deadline of the task is not usable (that is, if
"dl_time_before(p->dl.deadline, rq_clock(rq)"). So, dl_se->deadline
will be surely smaller than pi_se->deadline... But the inheritance has
to happen anyway.
> We seem to be doing the same elsewhere, but Luca was saying
> some time ago that the DI thing my have some problems and needs to be
> revised.
My doubts regarding the inheritance code currently used for -deadline
tasks are due to the fact that it is not clear which kind of
inheritance algorithm is used...
I think it should use deadline inheritance, that, AFAIK, says that when
task T1 block waiting for task T2, T2 can inherit T1's _absolute_
deadline - if it is earlier than T2's one.
But the current code seems to be using relative deadlines (dl_deadline)
to decide the inheritance...
Having a better look at this is in my TODO list... But I still need to
find some time :)
Luca
> Is is fair enough fixing this bit in accordance with the
> current (maybe broken) behaviour and then spend time reviewing the
> whole thing, or do we want to do both at the same time (which will of
> course require more time)?
>
> Best,
>
> - Juri
next prev parent reply other threads:[~2016-07-06 8:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 19:07 [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity Juri Lelli
2016-07-04 9:03 ` luca abeni
2016-07-04 9:28 ` Juri Lelli
2016-07-05 7:37 ` Wanpeng Li
2016-07-05 8:52 ` Juri Lelli
2016-07-05 14:20 ` Steven Rostedt
2016-07-05 14:39 ` Juri Lelli
2016-07-05 16:47 ` Steven Rostedt
2016-07-05 16:58 ` Juri Lelli
2016-07-06 8:44 ` luca abeni [this message]
2016-07-07 8:39 ` Juri Lelli
2016-07-07 13:47 ` Steven Rostedt
2016-07-08 11:32 ` Juri Lelli
2016-07-06 8:46 ` 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=20160706104411.0632d89f@utopia \
--to=luca.abeni@unitn.it \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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.