Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4074311imm; Mon, 15 Oct 2018 08:43:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV606QpgB2JyUIvep7qXEUJ6Ifn5Fgg61UR3ZsoEKxC7hVq+SN6TNXgsenldqB4NO5mvKto5O X-Received: by 2002:a17:902:9a8b:: with SMTP id w11-v6mr13261685plp.94.1539618187406; Mon, 15 Oct 2018 08:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539618187; cv=none; d=google.com; s=arc-20160816; b=bws+1+PjiCwqYNSfLfxCHW+bvU46dcaYr4VWrDjaXIJoKyl8m4QGV0qAa/vi+Nrtci /GJK3FIfKh/gUVA9vN4fN6Zw50LXqmPlif9iKUQSdwVNHKnmE45XvW2sDy8+eatQjLMW 3TOtY8u6XpaKuOMSIyILF/dblOOZsFgNswXgC4fJvBdgaQcZM3/APHUA7nz5Difb0APM LUs1RrzbTesi1aI9Mt71itXSoIGN+Ywo62jwx0K+5tYvQtFmcoRhdXCSg1/wOasPAje7 hdGlUdjzouKdM2zUurs3Kke+Xb9L0tag2vXaWQJOUXU17iULWv4TVVVJpq6J+mGHLdmQ IW4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=0FUwEbIutWIe//0hjZ9XJDwQUemYroI6dVi+VK078eE=; b=O+OmOoEs1cmPc9Q4oPEOWhvPFPRo3HAUUZtYbA4f9urIAn7XXfU9ja0Xtv6nuDCOlW uVOs2LoFE1dzOugy2/S8JbbEhCChotRI2QMHGBDQ6gkL2saaz1vyRFyF3xaMEOpAGm6Y ASx5YRpZvkP0OiZaiG7G1qENo+egQxrXXXzamGAYM3tZmZ+2M7+QLq0VITK7vspxOxqZ lYqvS+79ZHt1q5epeRFvnly//dlI6mM3SGsKiRhQFZ1bIAab64I8VqlWOdJGfEeiJaql zlBtCmcPaTtJFkdwlhRaVdyv6LrtziS93KSXd6KAsBqm3Hz/GMUs/aqUtLiqkY7ixz+O pxwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3-v6si1472177pld.93.2018.10.15.08.42.52; Mon, 15 Oct 2018 08:43:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726687AbeJOX2K (ORCPT + 99 others); Mon, 15 Oct 2018 19:28:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:49352 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbeJOX2J (ORCPT ); Mon, 15 Oct 2018 19:28:09 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4C5F72089D; Mon, 15 Oct 2018 15:42:22 +0000 (UTC) Date: Mon, 15 Oct 2018 11:42:20 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Peng Hao , mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] sched/rt : return accurate release rq lock info Message-ID: <20181015114220.70c3598d@gandalf.local.home> In-Reply-To: <20181015092032.GO9867@hirez.programming.kicks-ass.net> References: <1538778131-44406-1-git-send-email-peng.hao2@zte.com.cn> <20181015092032.GO9867@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Oct 2018 11:20:32 +0200 Peter Zijlstra wrote: > > index 2e2955a..be0fc43 100644 > > --- a/kernel/sched/rt.c > > +++ b/kernel/sched/rt.c > > @@ -1754,7 +1754,7 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) > > !task_on_rq_queued(task))) { > > > > double_unlock_balance(rq, lowest_rq); > > - lowest_rq = NULL; > > + lowest_rq = RETRY_TASK; > > break; > > } > > } > > I'm confused.. should not: > > /* try again */ > double_unlock_balance(rq, lowest_rq); > lowest_rq = NULL; > > also return RETRY_TASK? That also is in the double_lock_balance() path > and will this have had rq->lock() released. I thought the same thing at first, but this is in the loop path, where it does everything again. But now looking closer, I think there's a bug in the original code. We only do the check if the immediate double_lock_balance() released the current task rq lock, but we don't take into account if it was released earlier, which means it could have migrated and we never noticed! I believe the code should look like this: diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 2e2955a8cf8f..2c9128ce61e2 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1718,6 +1718,7 @@ static int find_lowest_rq(struct task_struct *task) static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) { struct rq *lowest_rq = NULL; + bool released = false; int tries; int cpu; @@ -1740,7 +1741,7 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) } /* if the prio of this runqueue changed, try again */ - if (double_lock_balance(rq, lowest_rq)) { + if (double_lock_balance(rq, lowest_rq) || released) { /* * We had to unlock the run queue. In * the mean time, task could have @@ -1754,7 +1755,7 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) !task_on_rq_queued(task))) { double_unlock_balance(rq, lowest_rq); - lowest_rq = NULL; + lowest_rq = RETRY_TASK; break; } } @@ -1764,10 +1765,15 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) break; /* try again */ - double_unlock_balance(rq, lowest_rq); + if (double_unlock_balance(rq, lowest_rq)) + released = true; + lowest_rq = NULL; } + if (!lowest_rq && released) + lowest_rq = RETRY_TASK; + return lowest_rq; } -- Steve