From: luca abeni <luca.abeni@unitn.it>
To: Juri Lelli <juri.lelli@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com
Subject: Re: [PATCH] sched/deadline: remove useless param from setup_new_dl_entity
Date: Fri, 17 Jun 2016 22:36:12 +0200 [thread overview]
Message-ID: <20160617223612.2c8bf505@utopia> (raw)
In-Reply-To: <20160617221518.75427592@utopia>
On Fri, 17 Jun 2016 22:15:18 +0200
luca abeni <luca.abeni@unitn.it> wrote:
> On Fri, 17 Jun 2016 17:28:37 +0100
> Juri Lelli <juri.lelli@arm.com> wrote:
> [...]
> > True, but we were practically already using the same parameter, under a
> > different name though, after
> >
> > 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
> >
> > as we currently do:
> >
> > setup_new_dl_entity(&p->dl, &p->dl)
> >
> > > This patch reverts part of the change done in
> > > commit 2d3d891d334 "sched/deadline: Add SCHED_DEADLINE inheritance
> > > logic"
> > >
> >
> > Before Luca's change we were doing
> >
> > setup_new_dl_entity(dl_se, pi_se)
> >
> > in update_dl_entity() for a dl_se->new entity. So, I guess the question
> > is actually why we wanted to use pi_se's parameters (the potential PI
> > donor) for setting up a new entity?
> That's a good question :)
>
> > Maybe we broke the situation where a
> > task is currently boosted by a DEADLINE waiter and we swich the holder
> > to DEADLINE?
> I remember I tested this setup (using linaro's version of rt-app), and
> it seemed to work correctly...
>
> Re-reading the code now, I actually wonder why my patch did not break
> inheritance in this situation...
Ok; I think I know why inheritance is not broken (or, at least, it does
not appear to be broken when testing it with rt-app):
- When a -deadline task blocks on a mutex that is held by a SCHED_OTHER
or SCHED_FIFO task, such a task is promoted to -deadline
- setup_new_dl_entity() is invoked, and it sets the tasks' deadline to
rq_clock(rq) (+ 0), so the task holding the lock is immediately
scheduled
- as soon as update_curr_dl() is invoked (in the worst case at the next
tick), the task's deadline and runtime are set to the "desired values"
(using pi_se)
So, the behaviour is not changed too much respect to the previous one.
Luca
next prev parent reply other threads:[~2016-06-17 20:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 9:48 [PATCH] sched/deadline: remove useless param from setup_new_dl_entity Juri Lelli
2016-06-17 9:58 ` luca abeni
2016-06-17 10:08 ` Juri Lelli
2016-06-17 13:49 ` Steven Rostedt
2016-06-17 16:28 ` Juri Lelli
2016-06-17 20:15 ` luca abeni
2016-06-17 20:36 ` luca abeni [this message]
2016-06-27 15:52 ` Peter Zijlstra
2016-06-27 17:24 ` 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=20160617223612.2c8bf505@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.