From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbdJPJw1 (ORCPT ); Mon, 16 Oct 2017 05:52:27 -0400 Received: from mga14.intel.com ([192.55.52.115]:11011 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750914AbdJPJw0 (ORCPT ); Mon, 16 Oct 2017 05:52:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,386,1503385200"; d="scan'208";a="163104150" Subject: Re: [RFC PATCH v2 3/8] cpuidle: add a new predict interface To: "Rafael J. Wysocki" , Aubrey Li Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com, ak@linux.intel.com, tim.c.chen@linux.intel.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org References: <1506756034-6340-1-git-send-email-aubrey.li@intel.com> <1506756034-6340-4-git-send-email-aubrey.li@intel.com> <3044561.Ej2KzLJlAU@aspire.rjw.lan> From: "Li, Aubrey" Message-ID: Date: Mon, 16 Oct 2017 17:52:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3044561.Ej2KzLJlAU@aspire.rjw.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/10/14 9:27, Rafael J. Wysocki wrote: >> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c >> index 0951dac..8704f3c 100644 >> --- a/kernel/sched/idle.c >> +++ b/kernel/sched/idle.c >> @@ -225,6 +225,7 @@ static void do_idle(void) >> */ >> __current_set_polling(); >> quiet_vmstat(); >> + cpuidle_predict(); > > One more question here. > > This changes the cpuidle code ordering such that if the ->predict callback > is present, the governor prediction will run before tick_nohz_idle_enter(), > whereas without that callback it runs in cpuidle_idle_call(). > > Is that actually going to work correctly for the menu governor, in particular? > This depends on how prediction works, patch 1/8 has the details. The first factor we get is the next clock event from tick device, this is not related to cpuidle call. The other two factors are derived from idle interval history, the data is already maintained in menu_device data structure. I'm not sure if this can address your concern, or anything else I can provide to help this. Thanks, -Aubrey