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

Message-ID: <adaebfb8-239c-8a0b-21b4-47150e6f2035@gmail.com>
Date:   Thu, 25 Aug 2016 23:46:34 +1000
From:   Balbir Singh <bsingharora@...il.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        "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 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.

@Gautham?


Balbir Singh.