From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v9 10/10] cpuidle: menu: Avoid selecting shallow states with stopped tick Date: Thu, 5 Apr 2018 14:47:57 +0200 Message-ID: <20180405124757.GQ4082@hirez.programming.kicks-ass.net> References: <1736751.LdhZHb50jq@aspire.rjw.lan> <6542020.eHGLEK9V0J@aspire.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <6542020.eHGLEK9V0J@aspire.rjw.lan> Sender: linux-kernel-owner@vger.kernel.org To: "Rafael J. Wysocki" Cc: Linux PM , Frederic Weisbecker , Thomas Gleixner , Paul McKenney , Thomas Ilsche , Doug Smythies , Rik van Riel , Aubrey Li , Mike Galbraith , LKML , Len Brown List-Id: linux-pm@vger.kernel.org On Wed, Apr 04, 2018 at 10:50:36AM +0200, Rafael J. Wysocki wrote: > + if (tick_nohz_tick_stopped()) { > + /* > + * If the tick is already stopped, the cost of possible short > + * idle duration misprediction is much higher, because the CPU > + * may be stuck in a shallow idle state for a long time as a > + * result of it. In that case say we might mispredict and try > + * to force the CPU into a state for which we would have stopped > + * the tick, unless the tick timer is going to expire really > + * soon anyway. Wait what; the tick was stopped, therefore it _cannot_ expire soon. *confused* Did you mean s/tick/a/ ? > + */ > + if (data->predicted_us < TICK_USEC) > + data->predicted_us = min_t(unsigned int, TICK_USEC, > + ktime_to_us(delta_next)); > + } else { > + /* > + * Use the performance multiplier and the user-configurable > + * latency_req to determine the maximum exit latency. > + */ > + interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load); > + if (latency_req > interactivity_req) > + latency_req = interactivity_req; > + } > > expected_interval = data->predicted_us; > /* >