Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1258741

Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us

From Rik van Riel <riel@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us
Date 2015-10-29 13:00 +0100
Message-ID <qoU25-89o-9@gated-at.bofh.it> (permalink)
References <qoI0V-Fc-3@gated-at.bofh.it> <qoI0W-Fc-19@gated-at.bofh.it> <qoStj-7jq-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 10/29/2015 06:17 AM, Daniel Lezcano wrote:
> 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.

With the current code, the default idle state is C1 (hlt) even if
C1 does not suit the constraint.

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

Why would we not care about break-even for C1?

On systems where going into C1 for too-short periods wastes
power, why would we waste the power when we expect a very
short sleep?

> 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.

We have hyper fast C1 exit on Nehalem and newer high performance
chips. On those chips, we will pick C1 (or deeper) when we have
an expected sleep time of just a few microseconds.

However, on Atom, and for the paravirt cpuidle driver I am
working on, C1 exit latency and target residence are higher
than the cut-off hardcoded in the menu governor.

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

And it will continue to be with this patch, on CPUs with
hyper fast C1 exit.

Which makes me confused about what your are objecting to,
since the system should continue to be have the way you want,
with the patch applied.

-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/3] cpuidle: small improvements & fixes for menu governor riel@redhat.com - 2015-10-29 00:10 +0100
  [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us riel@redhat.com - 2015-10-29 00:10 +0100
    Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to  20us Daniel Lezcano <daniel.lezcano@linaro.org> - 2015-10-29 11:20 +0100
      Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling  to 20us Rik van Riel <riel@redhat.com> - 2015-10-29 13:00 +0100
        Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to  20us Daniel Lezcano <daniel.lezcano@linaro.org> - 2015-10-29 14:10 +0100

csiph-web