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;
Date:   Fri, 5 Oct 2018 12:09:59 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     <peng.hao2@zte.com.cn>
Cc:     <andrea.parri@amarulasolutions.com>, <mingo@redhat.com>,
        <peterz@infradead.org>, <linux-kernel@vger.kernel.org>,
        <juri.lelli@redhat.com>
Subject: Re: [PATCH v3] sched/rt : return accurate release rq lock info
Message-ID: <20181005120959.6b8649e2@gandalf.local.home>
In-Reply-To: <201810060003580936940@zte.com.cn>
References: <20181005154632.GA18077@andrea>
        <201810060003580936940@zte.com.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, 6 Oct 2018 00:03:58 +0800 (CST)
<peng.hao2@zte.com.cn> wrote:

> >Hi Peng,  
> 
> >On Sat, Oct 06, 2018 at 06:22:11AM +0800, Peng Hao wrote:  
> >> find_lock_lowest_rq may or not releease rq lock when return
> >> lowest_rq=NULL, but it is fuzzy.
> >> If not releasing rq lock, it is unnecessary to re-call
> >> pick_next_pushable_task.  
> 
> >IIRC, deadline.c uses a similar pattern (c.f., find_lock_later_rq() and
> >pick_next_pushable_dl_task()): should it be considered for this change?  
> peterz asked the same question.
> at first I thought dl's retry action is simple. But now  the change is simpler, I will
> add it. 
>

I would still do that as a separate patch though.

-- Steve