From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031246AbdADOvD (ORCPT ); Wed, 4 Jan 2017 09:51:03 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:33670 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968112AbdADOuY (ORCPT ); Wed, 4 Jan 2017 09:50:24 -0500 Date: Wed, 4 Jan 2017 15:49:35 +0100 From: luca abeni To: linux-kernel@vger.kernel.org Cc: Juri Lelli , Peter Zijlstra , Daniel Bristot de Oliveira Subject: Doubt about push_dl_task() / find_lock_later_rq() Message-ID: <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 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... 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