From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753297AbdJNBXo (ORCPT ); Fri, 13 Oct 2017 21:23:44 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:54807 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751617AbdJNBXn (ORCPT ); Fri, 13 Oct 2017 21:23:43 -0400 From: "Rafael J. Wysocki" To: Aubrey Li Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com, ak@linux.intel.com, tim.c.chen@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Date: Sat, 14 Oct 2017 03:14:10 +0200 Message-ID: <3026355.QRuoy6eIZM@aspire.rjw.lan> In-Reply-To: <1506756034-6340-1-git-send-email-aubrey.li@intel.com> References: <1506756034-6340-1-git-send-email-aubrey.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday, September 30, 2017 9:20:26 AM CEST Aubrey Li wrote: > We found under some latency intensive workloads, short idle periods occurs > very common, then idle entry and exit path starts to dominate, so it's > important to optimize them. To determine the short idle pattern, we need > to figure out how long of the coming idle and the threshold of the short > idle interval. > > A cpu idle prediction functionality is introduced in this proposal to catch > the short idle pattern. > > Firstly, we check the IRQ timings subsystem, if there is an event > coming soon. > -- https://lwn.net/Articles/691297/ > > Secondly, we check the idle statistics of scheduler, if it's likely we'll > go into a short idle. > -- https://patchwork.kernel.org/patch/2839221/ > > Thirdly, we predict the next idle interval by using the prediction > fucntionality in the idle governor if it has. > > For the threshold of the short idle interval, we record the timestamps of > the idle entry, and multiply by a tunable parameter at here: > -- /proc/sys/kernel/fast_idle_ratio > > We use the output of the idle prediction to skip turning tick off if a > short idle is determined in this proposal. Reprogramming hardware timer > twice(off and on) is expensive for a very short idle. There are some > potential optimizations can be done according to the same indicator. > > I observed when system is idle, the idle predictor reports 20/s long idle > and ZERO fast idle on one CPU. And when the workload is running, the idle > predictor reports 72899/s fast idle and ZERO long idle on the same CPU. > > Aubrey Li (8): > cpuidle: menu: extract prediction functionality > cpuidle: record the overhead of idle entry > cpuidle: add a new predict interface > tick/nohz: keep tick on for a fast idle > timers: keep sleep length updated as needed > cpuidle: make fast idle threshold tunable > cpuidle: introduce irq timing to make idle prediction > cpuidle: introduce run queue average idle to make idle prediction > > drivers/cpuidle/Kconfig | 1 + > drivers/cpuidle/cpuidle.c | 109 +++++++++++++++++++++++++++++++++++++++ > drivers/cpuidle/governors/menu.c | 69 ++++++++++++++++--------- > include/linux/cpuidle.h | 21 ++++++++ > kernel/sched/idle.c | 14 ++++- > kernel/sysctl.c | 12 +++++ > kernel/time/tick-sched.c | 7 +++ > 7 files changed, 209 insertions(+), 24 deletions(-) > Overall, it looks like you could avoid stopping the tick every time the predicted idle duration is not longer than the tick interval in the first place. Why don't you do that?