Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754575AbdGNP7B (ORCPT ); Fri, 14 Jul 2017 11:59:01 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:33616 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754507AbdGNP7A (ORCPT ); Fri, 14 Jul 2017 11:59:00 -0400 Date: Fri, 14 Jul 2017 17:58:53 +0200 From: Peter Zijlstra To: Arjan van de Ven Cc: "Li, Aubrey" , Andi Kleen , Frederic Weisbecker , Christoph Lameter , Aubrey Li , tglx@linutronix.de, len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com, paulmck@linux.vnet.ibm.com, yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Message-ID: <20170714155853.xvoyyzjg6l2ytqx7@hirez.programming.kicks-ass.net> References: <20170712083410.ualmvnvzoohyami5@hirez.programming.kicks-ass.net> <20170712213240.GE3441@tassilo.jf.intel.com> <20170713083649.febfflfl5hafkko5@hirez.programming.kicks-ass.net> <16e12e23-6b28-f174-7c4b-4d719225cd3b@linux.intel.com> <20170713145311.z4zxlyd2dospeoqg@hirez.programming.kicks-ass.net> <4a577bd6-20b1-abb6-2153-f9870f0a721e@linux.intel.com> <20170713182820.sn3fjitnd3mca27p@hirez.programming.kicks-ass.net> <31170ac6-9db1-f0b8-4841-f1661c8ed6e1@linux.intel.com> <20170714153818.pjauqxebxyhs6ljp@hirez.programming.kicks-ass.net> <3d2d06e2-a2ee-bcf7-7727-07f72de5d32d@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d2d06e2-a2ee-bcf7-7727-07f72de5d32d@linux.intel.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 807 Lines: 17 On Fri, Jul 14, 2017 at 08:52:28AM -0700, Arjan van de Ven wrote: > On 7/14/2017 8:38 AM, Peter Zijlstra wrote: > > No, that's wrong. We want to fix the normal C state selection process to > > pick the right C state. > > > > The fast-idle criteria could cut off a whole bunch of available C > > states. We need to understand why our current C state pick is wrong and > > amend the algorithm to do better. Not just bolt something on the side. > > I can see a fast path through selection if you know the upper bound of any > selection is just 1 state. > > But also, how much of this is about "C1 be fast" versus "selecting C1 is slow" I got the impression its about we need to select C1 for longer. But the fact that the patches don't in fact answer any of these questions, they're wrong in principle ;-)