public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: riel@redhat.com, linux-kernel@vger.kernel.org
Cc: arjan@linux.intel.com, khilman@ti.com, len.brown@intel.com,
	rafael.j.wysocki@intel.com, javi.merino@arm.com,
	tuukka.tikkanen@linaro.org
Subject: Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us
Date: Thu, 29 Oct 2015 11:17:50 +0100	[thread overview]
Message-ID: <5631F24E.2060508@linaro.org> (raw)
In-Reply-To: <1446072416-13622-2-git-send-email-riel@redhat.com>

On 10/28/2015 11:46 PM, riel@redhat.com wrote:
> From: Rik van Riel <riel@redhat.com>
>
> The cpuidle menu governor has a forced cut-off for polling at 5us,
> in order to deal with firmware that gives the OS bad information
> on cpuidle states, leading to the system spending way too much time
> in polling.

May be I am misunderstanding your explanation but it is not how I read 
the code.

The default idle state is C1 (hlt) if no other states suits the 
constraint. If a timer is happening really soon, then set the default 
idle state to POLL if no other idle state suits the constraint.

That applies only on x86.

This is not related to break-even but exit latency.

IMO, we should just drop this 5us and the POLL state selection in the 
menu governor as we have since a while hyper fast C1 exit. Except a few 
embedded processors where polling is not adequate.

Furthermore, the number of times the poll state is selected vs the other 
states is negligible.

I already raised this point but Len is opposed to the removal.

Len ? Can you elaborate why you are opposed to this removal ?

> However, at least one x86 CPU family (Atom) has chips that have
> a 20us break-even point for C1. Forcing the polling cut-off to
> less than that wastes performance and power.
>
> Increase the polling cut-off to 20us.
>
> Systems with a lower C1 latency will be found in the states table by
> the menu governor, which will pick those states as appropriate.

With this change, I believe the poll state will be selected more often 
(not too much certainly), hence implying a bigger energy consumption.

And finally it may improve the situation for specific processor but 
deteriorate for other processors.

Does anyone have the rational behind this '5' number ? why not '3' or '7' ?

> Signed-off-by: Rik van Riel <riel@redhat.com>
> ---
>   drivers/cpuidle/governors/menu.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index 22e4463d1787..ecc242a586c9 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -330,7 +330,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>   	 * We want to default to C1 (hlt), not to busy polling
>   	 * unless the timer is happening really really soon.
>   	 */
> -	if (data->next_timer_us > 5 &&
> +	if (data->next_timer_us > 20 &&
>   	    !drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
>   		dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
>   		data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2015-10-29 10:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 22:46 [PATCH 0/3] cpuidle: small improvements & fixes for menu governor riel
2015-10-28 22:46 ` [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us riel
2015-10-29 10:17   ` Daniel Lezcano [this message]
2015-10-29 11:54     ` Rik van Riel
2015-10-29 13:02       ` Daniel Lezcano
2015-10-28 22:46 ` [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling riel
2015-10-28 22:46 ` [PATCH 3/3] cpuidle,menu: smooth out measured_us calculation riel
2015-11-03 22:05 ` [PATCH 0/3] cpuidle: small improvements & fixes for menu governor Rafael J. Wysocki
2015-11-03 22:35   ` Rik van Riel
2015-11-03 23:03     ` Rafael J. Wysocki
2015-11-04  6:56       ` Joe Perches
2015-11-04 14:02         ` Rafael J. Wysocki
2015-11-04 15:56           ` Joe Perches
  -- strict thread matches above, loose matches on Subject: below --
2015-11-03 22:34 [PATCH 0/3] cpuidle: small improvements & fixes for menu governor (resend) riel
2015-11-03 22:34 ` [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us riel
2015-11-04 16:00   ` Arjan van de Ven

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=5631F24E.2060508@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=arjan@linux.intel.com \
    --cc=javi.merino@arm.com \
    --cc=khilman@ti.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=riel@redhat.com \
    --cc=tuukka.tikkanen@linaro.org \
    /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