From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753183AbbJOUKS (ORCPT ); Thu, 15 Oct 2015 16:10:18 -0400 Received: from mail-lf0-f50.google.com ([209.85.215.50]:34998 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752145AbbJOUKQ (ORCPT ); Thu, 15 Oct 2015 16:10:16 -0400 Date: Thu, 15 Oct 2015 22:10:03 +0200 From: Luca Abeni To: Juri Lelli Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Wanpeng Li Subject: Re: [PATCH] Fix migration of SCHED_DEADLINE tasks Message-ID: <20151015221003.3ca75275@luca-1225C> In-Reply-To: <561FD6F3.4090209@arm.com> References: <1444907357-13114-1-git-send-email-luca.abeni@unitn.it> <561FD6F3.4090209@arm.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-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 Juri, On Thu, 15 Oct 2015 17:40:19 +0100 Juri Lelli wrote: > On 15/10/15 12:09, Luca Abeni wrote: > > Commit 9d5142624256 ("sched/deadline: Reduce rq lock contention by > > eliminating locking of non-feasible target") broke [...] > > cpu_rq(target)->dl.earliest_dl.curr)) > > + (dl_time_before(p->dl.deadline, > > + > > cpu_rq(target)->dl.earliest_dl.curr) || > > + > > (cpu_rq(target)->dl.earliest_dl.curr == 0))) > > Can't we actually use dl.dl_nr_running here and below, so > that we won't incur any wraparound problem? I copied the "earliest_dl.curr == 0" check from inc_dl_deadline(): if (dl_rq->earliest_dl.curr == 0 || dl_time_before(deadline, dl_rq->earliest_dl.curr)) { /* * If the dl_rq had no -deadline tasks, or if the new task * has shorter deadline than the current one on dl_rq, ... And init_dl_rq() has a comment saying "zero means no -deadline tasks"... But now I see what you mean: actually, find_lock_later_rq() contains the correct version of the check few lines below the wrong check (after acquiring the rq lock). Tomorrow I'll try the version of the check with later_rq->dl.dl_nr_running, and if it works I'll send an updated patch. Thanks, Luca