From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753423AbdJNBGB (ORCPT ); Fri, 13 Oct 2017 21:06:01 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:61937 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753250AbdJNBGA (ORCPT ); Fri, 13 Oct 2017 21:06:00 -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 5/8] timers: keep sleep length updated as needed Date: Sat, 14 Oct 2017 02:56:27 +0200 Message-ID: <1554921.dz8jk4n8cL@aspire.rjw.lan> In-Reply-To: <1506756034-6340-6-git-send-email-aubrey.li@intel.com> References: <1506756034-6340-1-git-send-email-aubrey.li@intel.com> <1506756034-6340-6-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:31 AM CEST Aubrey Li wrote: > sleep length indicates how long we'll be idle. Currently, it's updated > only when tick nohz enters. These patch series make a new requirement > with tick, so we should keep sleep length updated as needed So what exactly would be the problem with leaving things as they are? > --- > kernel/time/tick-sched.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index d663fab..94fb9b8 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -1008,8 +1008,11 @@ void tick_nohz_irq_exit(void) > */ > ktime_t tick_nohz_get_sleep_length(void) > { > + struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); > struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched); > > + ts->sleep_length = ktime_sub(dev->next_event, ktime_get()); > + > return ts->sleep_length; > } > > I probably wouldn't do it this way ...