On Thu, Jan 05, 2017 at 08:29:23AM +0100, luca abeni wrote: > On Wed, 4 Jan 2017 15:49:35 +0100 > luca abeni <luca.ab...@unitn.it> wrote: > > > Hi all, > > > > trying to debug a reclaiming issue discovered by Daniel, I find myself > > confused by the push logic... Maybe I am misunderstanding something > > very obvious, so I ask here: > > > > - push_dl_task() selects a task to be pushed, and then searches for a > > runqueue to push the task to by calling find_lock_later_rq() > > - if I understand well, find_lock_later_rq() checks all the candidate > > runqueues for pushing, and then compares the deadline of the task > > with "dl.earliest_dl.curr" of the candidate runqueue, to check if > > pushing the task there makes sense or not > > - now, my understanding is that in order to implement gEDF task T must > > be pushed on CPU C if the deadline of T is smaller than the earliest > > deadline of tasks on C... That is to say, the deadline of T must be > > smaller than the deadline of the task that is currently executing on > > C... No? > > - But as far as I understand "dl.earliest_dl.curr" is the earliest > > deadline of _pushable_ tasks that are on the remote runqueue... > > So, after re-reading the code I now see that my understanding here was > wrong: "dl.earliest_dl.curr" is really supposed to be the deadline of > the earliest deadline task on the runqueue... So, if I do not play > with affinities it should be the deadline of the task that is currently > executing on that CPU. > So, everything is fine.
Right, that's what I remember. > > I was confused by the fact that in some cases I saw > rq->dl.earliest_dl.curr != rq->curr->dl.deadline > > I still do not understand how this can happen (I am not changing tasks > affinities), and I am investigating this. I'm having trouble spotting code that does that...
