Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Tuesday, March 6, 2018 12:27:01 AM CET Rik van Riel wrote: > On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > > > +++ linux-pm/kernel/sched/idle.c > > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > > } else { > > unsigned int duration_us; > > > > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Tuesday, March 6, 2018 12:27:01 AM CET Rik van Riel wrote: > On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > > > +++ linux-pm/kernel/sched/idle.c > > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > > } else { > > unsigned int duration_us; > > > > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > } else { > unsigned int duration_us; > > - tick_nohz_idle_go_idle(true); > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > } else { > unsigned int duration_us; > > - tick_nohz_idle_go_idle(true); > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 04:36:20PM +0100, Thomas Ilsche wrote: > I fear that might even create positive feedback loops on the > heuristic, which will take into account the sleep durations for > sched tick wakeups in sort of a self fulfilling prophecy: > 1) The heuristic predicts to wake up in less

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 04:36:20PM +0100, Thomas Ilsche wrote: > I fear that might even create positive feedback loops on the > heuristic, which will take into account the sleep durations for > sched tick wakeups in sort of a self fulfilling prophecy: > 1) The heuristic predicts to wake up in less

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On 2018-03-04 23:28, Rafael J. Wysocki wrote: use the expected idle period duration returned by cpuidle_select() to tell tick_nohz_idle_go_idle() whether or not to stop the tick. I assume that at the point of going idle, the actual next scheduling tick may happen anywhere between now and 1/HZ.

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On 2018-03-04 23:28, Rafael J. Wysocki wrote: use the expected idle period duration returned by cpuidle_select() to tell tick_nohz_idle_go_idle() whether or not to stop the tick. I assume that at the point of going idle, the actual next scheduling tick may happen anywhere between now and 1/HZ.

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 02:37:25PM +0100, Peter Zijlstra wrote: > On Mon, Mar 05, 2018 at 08:19:15AM -0500, Rik van Riel wrote: > > > Also, I think that at this point you've introduced a problem; by not > > > disabling the tick unconditionally, we'll have extra wakeups due to > > > the (now still

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 02:37:25PM +0100, Peter Zijlstra wrote: > On Mon, Mar 05, 2018 at 08:19:15AM -0500, Rik van Riel wrote: > > > Also, I think that at this point you've introduced a problem; by not > > > disabling the tick unconditionally, we'll have extra wakeups due to > > > the (now still

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 08:19:15AM -0500, Rik van Riel wrote: > > Also, I think that at this point you've introduced a problem; by not > > disabling the tick unconditionally, we'll have extra wakeups due to > > the (now still running) tick, which will bias the estimation, as per > > reflect(),

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 08:19:15AM -0500, Rik van Riel wrote: > > Also, I think that at this point you've introduced a problem; by not > > disabling the tick unconditionally, we'll have extra wakeups due to > > the (now still running) tick, which will bias the estimation, as per > > reflect(),

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, 2018-03-05 at 13:35 +0100, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > Index: linux-pm/kernel/sched/idle.c > > === > > --- linux-pm.orig/kernel/sched/idle.c > > +++

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, 2018-03-05 at 13:35 +0100, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > Index: linux-pm/kernel/sched/idle.c > > === > > --- linux-pm.orig/kernel/sched/idle.c > > +++

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 1:42 PM, Peter Zijlstra wrote: > On Mon, Mar 05, 2018 at 01:07:07PM +0100, Rafael J. Wysocki wrote: >> On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: >> > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 1:42 PM, Peter Zijlstra wrote: > On Mon, Mar 05, 2018 at 01:07:07PM +0100, Rafael J. Wysocki wrote: >> On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: >> > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra >> > wrote: > >> >> So I think this is entirely wrong, I

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 1:35 PM, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >> Index: linux-pm/kernel/sched/idle.c >> === >> --- linux-pm.orig/kernel/sched/idle.c

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 1:35 PM, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >> Index: linux-pm/kernel/sched/idle.c >> === >> --- linux-pm.orig/kernel/sched/idle.c >> +++

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 01:07:07PM +0100, Rafael J. Wysocki wrote: > On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: > > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra > > wrote: > >> So I think this is entirely wrong, I would much rather see

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 05, 2018 at 01:07:07PM +0100, Rafael J. Wysocki wrote: > On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: > > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra > > wrote: > >> So I think this is entirely wrong, I would much rather see something > >> like: > >> > >>

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra wrote: >> On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >>> Index: linux-pm/kernel/sched/idle.c >>>

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 12:50 PM, Rafael J. Wysocki wrote: > On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra wrote: >> On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >>> Index: linux-pm/kernel/sched/idle.c >>> ===

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >> Index: linux-pm/kernel/sched/idle.c >> === >> --- linux-pm.orig/kernel/sched/idle.c

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: >> Index: linux-pm/kernel/sched/idle.c >> === >> --- linux-pm.orig/kernel/sched/idle.c >> +++

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void

[RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

From: Rafael J. Wysocki In order to address the issue with short idle duration predictions by the idle governor after the tick has been stopped, reorder the code in cpuidle_idle_call() so that the governor idle state selection runs before tick_nohz_idle_go_idle() and

[RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

From: Rafael J. Wysocki In order to address the issue with short idle duration predictions by the idle governor after the tick has been stopped, reorder the code in cpuidle_idle_call() so that the governor idle state selection runs before tick_nohz_idle_go_idle() and use the expected idle period