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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2015 07:54:36 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	linux-kernel@...r.kernel.org
CC:	arjan@...ux.intel.com, khilman@...com, len.brown@...el.com,
	rafael.j.wysocki@...el.com, javi.merino@....com,
	tuukka.tikkanen@...aro.org
Subject: Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling
 to 20us

On 10/29/2015 06:17 AM, Daniel Lezcano wrote:
> On 10/28/2015 11:46 PM, riel@...hat.com wrote:
>> From: Rik van Riel <riel@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/