From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751315AbdBWNQA (ORCPT <rfc822;w@1wt.eu>);
        Thu, 23 Feb 2017 08:16:00 -0500
Received: from mout.gmx.net ([212.227.17.20]:51093 "EHLO mout.gmx.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751049AbdBWNP5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 23 Feb 2017 08:15:57 -0500
Message-ID: <1487855304.4463.50.camel@gmx.de>
Subject: Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency
 consideration
From: Mike Galbraith <efault@gmx.de>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Alex Shi <alex.shi@linaro.org>, Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Rik van Riel <riel@redhat.com>
Date: Thu, 23 Feb 2017 14:08:24 +0100
In-Reply-To: <2050688.jCOqd8xbcD@aspire.rjw.lan>
References: <1487768197.27533.5.camel@gmx.de>
         <20170222143910.GV6515@twins.programming.kicks-ass.net>
         <47a10932-b485-cf3f-bf39-ccf3026a960f@linaro.org>
         <2050688.jCOqd8xbcD@aspire.rjw.lan>
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Evolution 3.16.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:YrzyoeUI8OjIiSjP+MtTFFateN1ADDXU4ezS0xopHRqpMcoTFJp
 OnB85KmwznbnveTjEOR4dD0+9hJeX65AZX7dKB9TTqJKolhyqp8z1YpUSaT1vc0Dcybq+Y2
 8r1J+NP13fc3NEV731slBjvHiVJpP8NyqcUR0g+aoWet11f0EwnlfaaywqhpbcmX7y5z2xk
 pJLmu8FHThQu1rKD3eIEA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:1+WlHTKehDE=:zUBz239RDN4YvoWfMfgyGQ
 z9QQni/8iSIEwDOron8sSBjQBb9pZVk0gOG6Y5ifzgfHC5CTR+eH4XgaW05A4z4cw4a4MsK4u
 3jVL7CEqrXRxR5pLdONcuorcPtS/3qMYUn1XwXCmdWK0dv50aFkD8KX1pFqHzbxUTPyAHc4YY
 hx6ozGeoXcqWhTmhlRrzAX9epoqrBGC4hDLNkmzLT7ZI61fBsEr0eSYtqfk2bgMbG7vEeezVC
 nBZRG2PwhgiA2gZfzcdlLDle81aKyPjCkflGYrdGasOhuTdHzV2KXfAgjIVk78So/N4WqdlEE
 Q6WW84Hr0LrBXvpQLjgjM608NPILaP1CCVWgyurYUJQx/QwxTPGo0z7PdQe0k3gl/WXuO9KQx
 rMEv+0jl1ZS3wKEyJ0DykBLUQ0eiBmUn//ZgfufXZKPEZU54p4GnaRMc3OG2l782Lq6y09TXr
 NbkUoxGhiBRFnMADam0N5HsZmV0HD8yGEB0FhXNGzEjssF0Vb1T9gbK6aon/CKFh7j9rAJmSo
 CTphi1wS9w2wWfVsamltTEmXaaV3fjv++61DyIpb50+NSaVXaaedcwDtCd548StpSYDGcvMBb
 gM+G4fuE6YtUIHZo//tN0VOE/GvYdh/lrjM0vjClP9aIj/bTxZ6MZ3Xg49gIgM0CyzjEmn5s6
 MtvrzgFtxyErPQYwPmSEivrHYPgQ28D5bRaIV1S1AAZX1U+Gw1AqH9PO/1pnam4T/h/+jAmon
 arAHjaclGIW8phKMnFYDgM1NkL7L/9Wx0goGYcFn3YFXPjDBSTbZ8IJG9jDQocRO3gjB79m+h
 e1oHHfV
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2017-02-23 at 13:15 +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote:
> > > 
> > > Its not hard; spinlock_t ends up being a mutex, and this is ran
> > > from the
> > > idle thread. What thread do you think we ought to run when we
> > > block
> > > idle?
> > > 
> > 
> > Straight right.
> > Thanks for explanations! :)
> 
> I overlooked that, sorry.
> 
> Shall we revert?
> 
> I don't want RT to be broken because of this.

Just whacking the lock would take care of that.  The question is who is
gonna use this, and what does it really buy them?  When I look at that
commit, an eyebrow raises, lock or no lock.

	-Mike