On Fri, 17 Jun 2016 22:15:18 +0200 luca abeni <[email protected]> wrote:
> On Fri, 17 Jun 2016 17:28:37 +0100 > Juri Lelli <[email protected]> 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
