Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751480AbdGRG72 (ORCPT ); Tue, 18 Jul 2017 02:59:28 -0400 Received: from mga05.intel.com ([192.55.52.43]:38057 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbdGRG71 (ORCPT ); Tue, 18 Jul 2017 02:59:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,377,1496127600"; d="scan'208";a="1173792559" Date: Mon, 17 Jul 2017 23:59:26 -0700 From: Andi Kleen To: Thomas Gleixner Cc: "Li, Aubrey" , Peter Zijlstra , Frederic Weisbecker , Christoph Lameter , Aubrey Li , len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com, arjan@linux.intel.com, paulmck@linux.vnet.ibm.com, yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Message-ID: <20170718065926.GP3441@tassilo.jf.intel.com> References: <20170713182820.sn3fjitnd3mca27p@hirez.programming.kicks-ass.net> <31170ac6-9db1-f0b8-4841-f1661c8ed6e1@linux.intel.com> <20170714153818.pjauqxebxyhs6ljp@hirez.programming.kicks-ass.net> <20170714155356.GH3441@tassilo.jf.intel.com> <20170714160648.tg2u6eo2id6gmnjz@hirez.programming.kicks-ass.net> <20170714162619.GJ3441@tassilo.jf.intel.com> <20170717192309.ubn5muvc3u7htuaw@hirez.programming.kicks-ass.net> <34371ef8-b8bc-d2bf-93de-3fccd6beb032@linux.intel.com> <20170718044521.GO3441@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1385 Lines: 35 On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Andi Kleen wrote: > > > > We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > > > it's better than menu governor. > > > > I still would like to see how the fast path without the C1 heuristic works. > > > > Fast pathing is a different concept from a better predictor. IMHO we need > > both, but the first is likely lower hanging fruit. > > Hacking something on the side is always the lower hanging fruit as it > avoids solving the hard problems. As Peter said already, that's not going > to happen unless there is a real technical reason why the general path > cannot be fixed. So far there is no proof for that. You didn't look at Aubrey's data? There are some unavoidable slow operations in the current path -- e.g. reprograming the timer for NOHZ. But we don't need that for really short idle periods, because as you pointed out they never get woken up by the tick. Similar for other things like RCU. I don't see how you can avoid that other than without a fast path mechanism. Clearly these operations are eventually needed, just not all the time for short sleeps. Now in theory you could have lots of little fast paths in all the individual operations that check this individually, but I don't see how that is better than a single simple fast path. -Andi