[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180402212508.GB19895@lerouge>
Date: Mon, 2 Apr 2018 23:25:09 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Thomas Ilsche <thomas.ilsche@...dresden.de>,
Doug Smythies <dsmythies@...us.net>,
Rik van Riel <riel@...riel.com>,
Aubrey Li <aubrey.li@...ux.intel.com>,
Mike Galbraith <mgalbraith@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
Len Brown <len.brown@...el.com>
Subject: Re: [PATCH v8 03/10] sched: idle: Do not stop the tick before
cpuidle_idle_call()
On Thu, Mar 29, 2018 at 02:02:24PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Make cpuidle_idle_call() decide whether or not to stop the tick.
>
> First, the cpuidle_enter_s2idle() path deals with the tick (and with
> the entire timekeeping for that matter) by itself and it doesn't need
> the tick to be stopped beforehand.
>
> Second, to address the issue with short idle duration predictions
> by the idle governor after the tick has been stopped, it will be
> necessary to change the ordering of cpuidle_select() with respect
> to tick_nohz_idle_stop_tick(). To prepare for that, put a
> tick_nohz_idle_stop_tick() call in the same branch in which
> cpuidle_select() is called.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Rewiewed-by: Frederic Weisbecker <frederic@...nel.org>
Powered by blists - more mailing lists