Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752102AbbEKDtL (ORCPT ); Sun, 10 May 2015 23:49:11 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:35569 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbbEKDtG (ORCPT ); Sun, 10 May 2015 23:49:06 -0400 Message-ID: <555026AA.20709@linux.vnet.ibm.com> Date: Mon, 11 May 2015 09:18:58 +0530 From: Preeti U Murthy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rafael J. Wysocki" , peterz@infradead.org CC: tglx@linutronix.de, rafael.j.wysocki@intel.com, daniel.lezcano@linaro.org, rlippert@google.com, linux-pm@vger.kernel.org, linus.walleij@linaro.org, linux-kernel@vger.kernel.org, mingo@redhat.com, sudeep.holla@arm.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures References: <20150508073418.28491.4150.stgit@preeti.in.ibm.com> <10239011.l6QLHlKIVm@vostro.rjw.lan> <3161640.llJtBoKCBr@vostro.rjw.lan> <8965830.CMQzZzsqm0@vostro.rjw.lan> In-Reply-To: <8965830.CMQzZzsqm0@vostro.rjw.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15051103-8236-0000-0000-00000B5FB9E4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1956 Lines: 54 On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote: > On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: >> On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: >>> On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: >>>> Hi Rafael, >>>> >>>> On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: >>> >>> [cut] >>> >>>>>> >>>>>> + /* Take note of the planned idle state. */ >>>>>> + idle_set_state(smp_processor_id(), target_state); >>>>> >>>>> And I wouldn't do this either. >>>>> >>>>> The behavior here is pretty much as though the driver demoted the state chosen >>>>> by the governor and we don't call idle_set_state() again in those cases. >>>> >>>> Why is this wrong? >>> >>> It is not "wrong", but incomplete, because demotions done by the cpuidle driver >>> should also be taken into account in the same way. >>> >>> But I'm seeing that the recent patch of mine that made cpuidle_enter_state() >>> call default_idle_call() was a mistake, because it might confuse find_idlest_cpu() >>> significantly as to what state the CPU is in. I'll drop that one for now. >> >> OK, done. >> >> So after I've dropped it I think we need to do three things: >> (1) Move the idle_set_state() calls to cpuidle_enter_state(). >> (2) Make cpuidle_enter_state() call default_idle_call() again, but this time >> do that *before* it has called idle_set_state() for target_state. >> (3) Introduce demotion as per my last patch. >> >> Let me cut patches for that. > > Done as per the above and the patches follow in replies to this messge. > > All on top of the current linux-next branch of the linux-pm.git tree. I don't see the patches on linux-pm/linux-next. Regards Preeti U Murthy > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/