From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968049AbdAEHaY (ORCPT ); Thu, 5 Jan 2017 02:30:24 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:36480 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967997AbdAEH3h (ORCPT ); Thu, 5 Jan 2017 02:29:37 -0500 Date: Thu, 5 Jan 2017 08:29:23 +0100 From: luca abeni To: linux-kernel@vger.kernel.org Cc: Juri Lelli , Peter Zijlstra , Daniel Bristot de Oliveira Subject: Re: Doubt about push_dl_task() / find_lock_later_rq() Message-ID: <20170105082923.639adcf9@sweethome> In-Reply-To: <20170104154935.7f08d550@sweethome> References: <20170104154935.7f08d550@sweethome> Organization: university of trento X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Jan 2017 15:49:35 +0100 luca abeni 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. 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. Thanks, Luca > That > is to say, "earliest_dl.curr" does not consider the deadline of the > task currently executing on the remote runqueue > - So, it seems to me that tasks are sometimes pushed to other > runqueues even if they have a deadline that is not smaller than the > deadline of the task executing on the "target" runqueue (so, a task > is pushed but not immediately scheduled for execution). Is this > correct? What is the logic behind this behaviour? > I would be tempted to say that the correct check is not > dl_time_before(task->dl.deadline, > later_rq->dl.earliest_dl.curr) (as it is now in > find_lock_later_rq()), but dl_time_before(task->dl.deadline, > later_rq->curr->dl.deadline) This, in my view, would migrate a task > only when it is going to preempt the current of the remote runqueue. > What am I missing? > > > Thanks, > Luca