public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
	Doug Smythies <dsmythies@telus.net>,
	Rik van Riel <riel@surriel.com>,
	Aubrey Li <aubrey.li@linux.intel.com>,
	Mike Galbraith <mgalbraith@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFT][PATCH v4 4/7] cpuidle: Return nohz hint from cpuidle_select()
Date: Thu, 15 Mar 2018 13:54:59 +0100	[thread overview]
Message-ID: <1998970.adS4ugIWGe@aspire.rjw.lan> (raw)
In-Reply-To: <20180314125929.GU4043@hirez.programming.kicks-ass.net>

On Wednesday, March 14, 2018 1:59:29 PM CET Peter Zijlstra wrote:
> On Mon, Mar 12, 2018 at 10:54:18AM +0100, Rafael J. Wysocki wrote:
> > @@ -378,6 +384,26 @@ static int menu_select(struct cpuidle_dr
> >  	if (idx == -1)
> >  		idx = 0; /* No states enabled. Must use 0. */
> >  
> > +	if (drv->states[idx].flags & CPUIDLE_FLAG_POLLING) {
> > +		*nohz_ret = false;
> > +	} else if (drv->states[idx].target_residency < TICK_USEC_HZ) {
> > +		first_idx = idx;
> > +		for (i = idx + 1; i < drv->state_count; i++) {
> > +			if (!drv->states[i].disabled &&
> > +			    !dev->states_usage[i].disable) {
> > +				first_idx = i;
> > +				break;
> > +			}
> 		}
> > +
> > +		/*
> > +		 * Do not stop the tick if there is at least one more state
> > +		 * within the tick period range that could be used if longer
> > +		 * idle duration was predicted.
> > +		 */
> > +		*nohz_ret = !(first_idx > idx &&
> > +			      drv->states[first_idx].target_residency < TICK_USEC_HZ);
> 
> 
> Why though? That comment only states what it does, but gives no clue as
> to why we're doing this. What was wrong with disabling NOHZ if the
> selected state (@idx) has shorter target residency.
> 
> 
> > +	}
> > +
> >  	data->last_state_idx = idx;
> >  
> >  	return data->last_state_idx;
> > 
> 

I invented this complicated logic because of the concern that using
predicted_us alone may skew the prediction algotithm too much towards
the lower values, so the idea was (roughly) to allow CPUs to be idle
for longer times more aggressively.  That is, to stop the tick even
in some cases in which predicted_us was below the tick period length,
but then again not too often.

It appears to work, but you are right that it is confusing and on
a second thought simpler code is always better as long as it gets the
job done.

I'll rework this and resend the series later today.

Thanks!

  reply	other threads:[~2018-03-15 12:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12  9:46 [RFT][PATCH v4 0/7] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-03-12  9:47 ` [RFT][PATCH v4 1/7] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-14 15:49   ` Frederic Weisbecker
2018-03-14 17:20     ` Peter Zijlstra
2018-03-15 17:26       ` Frederic Weisbecker
2018-03-15 12:33     ` Rafael J. Wysocki
2018-03-12  9:51 ` [RFT][PATCH v4 2/7] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-15 16:10   ` Frederic Weisbecker
2018-03-15 16:50     ` Rafael J. Wysocki
2018-03-12  9:53 ` [RFT][PATCH v4 3/7] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-15 18:19   ` Frederic Weisbecker
2018-03-15 20:41     ` Rafael J. Wysocki
2018-03-15 21:12       ` Rafael J. Wysocki
2018-03-16 14:17         ` Frederic Weisbecker
2018-03-16 14:16       ` Frederic Weisbecker
2018-03-12  9:54 ` [RFT][PATCH v4 4/7] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-14 12:59   ` Peter Zijlstra
2018-03-15 12:54     ` Rafael J. Wysocki [this message]
2018-03-12 10:04 ` [RFT][PATCH v4 5/7] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-12 10:05 ` [RFT][PATCH v4 6/7] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-12 10:07 ` [RFT][PATCH v4 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1998970.adS4ugIWGe@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=aubrey.li@linux.intel.com \
    --cc=dsmythies@telus.net \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgalbraith@suse.de \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.ilsche@tu-dresden.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox