From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Balbir Singh <bsingharora@gmail.com>,
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Neuling <michael.neuling@au1.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Anton Blanchard <anton@samba.org>
Subject: Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start
Date: Thu, 25 Aug 2016 16:07:58 +0200 [thread overview]
Message-ID: <57BEFBBE.8050601@linaro.org> (raw)
In-Reply-To: <adaebfb8-239c-8a0b-21b4-47150e6f2035@gmail.com>
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@linux.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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Balbir Singh <bsingharora@gmail.com>,
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Neuling <michael.neuling@au1.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Anton Blanchard <anton@samba.org>,
linux-pm@vger.kernel.org
Subject: Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start
Date: Thu, 25 Aug 2016 16:07:58 +0200 [thread overview]
Message-ID: <57BEFBBE.8050601@linaro.org> (raw)
In-Reply-To: <adaebfb8-239c-8a0b-21b4-47150e6f2035@gmail.com>
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@linux.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
next prev parent reply other threads:[~2016-08-25 14:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 22:26 [RFC/PATCH 0/2] powernv:cpuidle: Enable winkle idle state Gautham R. Shenoy
2016-08-18 22:26 ` Gautham R. Shenoy
2016-08-18 22:26 ` [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start Gautham R. Shenoy
2016-08-18 22:26 ` Gautham R. Shenoy
2016-08-24 14:44 ` Daniel Lezcano
2016-08-24 14:48 ` Balbir Singh
2016-08-24 14:48 ` Balbir Singh
2016-08-24 15:06 ` Daniel Lezcano
2016-08-25 13:46 ` Balbir Singh
2016-08-25 14:07 ` Daniel Lezcano [this message]
2016-08-25 14:07 ` Daniel Lezcano
2016-08-18 22:26 ` [RFC/PATCH 2/2] powernv:cpuidle: Enable winkle idle state in CPU-Idle Gautham R. Shenoy
2016-08-18 22:26 ` Gautham R. Shenoy
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=57BEFBBE.8050601@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=bsingharora@gmail.com \
--cc=ego@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michael.neuling@au1.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rjw@rjwysocki.net \
--cc=svaidy@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.