linux-kernel - Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start

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] [day] [month] [year] [list]

Message-ID: <57BEFBBE.8050601@linaro.org>
Date:   Thu, 25 Aug 2016 16:07:58 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Balbir Singh <bsingharora@...il.com>,
        "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Michael Neuling <michael.neuling@....ibm.com>,
        Paul Mackerras <paulus@...ba.org>,
        Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        Anton Blanchard <anton@...ba.org>, linux-pm@...r.kernel.org
Subject: Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at
 start

On 08/25/2016 03:46 PM, Balbir Singh wrote:
> 
> 
> On 25/08/16 01:06, Daniel Lezcano wrote:
>> On 08/24/2016 04:48 PM, Balbir Singh wrote:
>>>
>>>
>>> On 25/08/16 00:44, Daniel Lezcano wrote:
>>>> On 08/19/2016 12:26 AM, Gautham R. Shenoy wrote:
>>>>> From: "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>
>>>>>
>>>>> Currently all the idle states registered by a cpu-idle driver are
>>>>> enabled by default. This patch adds a mechanism which allows the
>>>>> driver to hint if an idle-state should start in a disabled state. The
>>>>> cpu-idle core will use this hint to appropriately initialize the
>>>>> usage->disable knob of the CPU device idle state.
>>>>
>>>> Why do you need to do that ?
>>>>
>>>
>>> I think patch 2/2 explains the reason as it uses this infrastructure
>>
>> Ok, let me elaborate the question, I was not clear.
>>
>> Why the userspace can't setup the system environment at boot time by
>> disabling the state instead of adding extra code to disable it at boot
>> time in the kernel and then re-enable it from userspace ?
> 
> Gautham's patches don't want to have those states enabled by default.
> They are unlikely to be what production systems need, but likely
> what a knowledgeable person can look into selectively enable for
> experimentation.

Why not invert the logic ?

A knowledgeable person can look into selectively disable for production.

In addition, a kernel command line option to specify which state to
disable would be appropriate and beneficial for all existing drivers.


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