linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: "Shreyas B. Prabhu" <shreyas@linux.vnet.ibm.com>, rjw@rjwysocki.net
Cc: linux-pm@vger.kernel.org, daniel.lezcano@linaro.org,
	anton@samba.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] cpuidle/powernv: Fix snooze timeout
Date: Thu, 23 Jun 2016 09:48:59 +1000	[thread overview]
Message-ID: <576B23EB.7080903@gmail.com> (raw)
In-Reply-To: <1466624203-1847-1-git-send-email-shreyas@linux.vnet.ibm.com>



On 23/06/16 05:36, Shreyas B. Prabhu wrote:
> Snooze is a poll idle state in powernv and pseries platforms. Snooze
> has a timeout so that if a cpu stays in snooze for more than target
> residency of the next available idle state, then it would exit thereby
> giving chance to the cpuidle governor to re-evaluate and
> promote the cpu to a deeper idle state. Therefore whenever snooze exits
> due to this timeout, its last_residency will be target_residency of next
> deeper state.
> 
> commit e93e59ce5b85 ("cpuidle: Replace ktime_get() with local_clock()")
> changed the math around last_residency calculation. Specifically, while
> converting last_residency value from nanoseconds to microseconds it does
> right shift by 10. Due to this, in snooze timeout exit scenarios
> last_residency calculated is roughly 2.3% less than target_residency of
> next available state. This pattern is picked up get_typical_interval()
> in the menu governor and therefore expected_interval in menu_select() is
> frequently less than the target_residency of any state but snooze.
> 
> Due to this we are entering snooze at a higher rate, thereby affecting
> the single thread performance.
> Since the math around last_residency is not meant to be precise, fix this
> issue setting snooze timeout to 105% of target_residency of next
> available idle state.
> 
> This also adds comment around why snooze timeout is necessary.
> 
> Reported-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
> ---
>  drivers/cpuidle/cpuidle-powernv.c | 14 ++++++++++++++
>  drivers/cpuidle/cpuidle-pseries.c | 13 +++++++++++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
> index e12dc30..5835491 100644
> --- a/drivers/cpuidle/cpuidle-powernv.c
> +++ b/drivers/cpuidle/cpuidle-powernv.c
> @@ -268,10 +268,24 @@ static int powernv_idle_probe(void)
>  		cpuidle_state_table = powernv_states;
>  		/* Device tree can indicate more idle states */
>  		max_idle_state = powernv_add_idle_states();
> +
> +		/*
> +		 * Staying in snooze for a long period can degrade the
> +		 * perfomance of the sibling cpus. Set timeout for snooze such
> +		 * that if the cpu stays in snooze longer than target residency
> +		 * of the next available idle state then exit from snooze. This
> +		 * gives a chance to the cpuidle governor to re-evaluate and
> +		 * promote it to deeper idle states.
> +		 */
>  		if (max_idle_state > 1) {
>  			snooze_timeout_en = true;
>  			snooze_timeout = powernv_states[1].target_residency *
>  					 tb_ticks_per_usec;
> +			/*
> +			 * Give a 5% margin since target residency related math
> +			 * is not precise in cpuidle core.
> +			 */

Is this due to the microsecond conversion mentioned above? It would be nice to
have it in the comment. Does

(powernv_states[1].target_residency + tb_ticks_per_usec) / tb_ticks_per_usec solve
your rounding issues, assuming the issue is really rounding or maybe it is due
to the shift by 10, could you please elaborate on what related math is not
precise? That would explain to me why I missed understanding your changes.

> +			snooze_timeout += snooze_timeout / 20;

For now 5% is sufficient, but do you want to check to assert to check if

snooze_timeout (in microseconds) / tb_ticks_per_usec > powernv_states[i].target_residency?

>  		}
>   	} else
>   		return -ENODEV;
> diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
> index 07135e0..22de841 100644
> --- a/drivers/cpuidle/cpuidle-pseries.c
> +++ b/drivers/cpuidle/cpuidle-pseries.c
> @@ -250,10 +250,23 @@ static int pseries_idle_probe(void)
>  	} else
>  		return -ENODEV;
>  
> +	/*
> +	 * Staying in snooze for a long period can degrade the
> +	 * perfomance of the sibling cpus. Set timeout for snooze such
> +	 * that if the cpu stays in snooze longer than target residency
> +	 * of the next available idle state then exit from snooze. This
> +	 * gives a chance to the cpuidle governor to re-evaluate and
> +	 * promote it to deeper idle states.
> +	 */
>  	if (max_idle_state > 1) {
>  		snooze_timeout_en = true;
>  		snooze_timeout = cpuidle_state_table[1].target_residency *
>  				 tb_ticks_per_usec;
> +		/*
> +		 * Give a 5% margin since target residency related math
> +		 * is not precise in cpuidle core.
> +		 */
> +		snooze_timeout += snooze_timeout / 20;
>  	}
>  	return 0;
>  }
> 

  parent reply	other threads:[~2016-06-22 23:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 19:36 [PATCH] cpuidle/powernv: Fix snooze timeout Shreyas B. Prabhu
2016-06-22 22:49 ` Rafael J. Wysocki
2016-06-22 23:48 ` Balbir Singh [this message]
2016-06-23  4:58   ` Shreyas B Prabhu
2016-06-23  9:28     ` Balbir Singh
2016-06-23  9:41       ` Shreyas B Prabhu
2016-06-23  9:55         ` Balbir Singh
2016-06-23 10:01       ` Daniel Lezcano
2016-06-23 13:35         ` Shreyas B Prabhu
2016-06-23 14:36           ` Daniel Lezcano

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=576B23EB.7080903@gmail.com \
    --to=bsingharora@gmail.com \
    --cc=anton@samba.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rjw@rjwysocki.net \
    --cc=shreyas@linux.vnet.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).