On 04/01/2016 12:14 PM, Rafael J. Wysocki wrote:
> On Fri, Apr 1, 2016 at 7:49 PM, Steve Muckle wrote:
>> On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote:
>> ...
>>> +config CPU_FREQ_GOV_SCHEDUTIL
>>> + tristate "'schedutil' cpufreq policy governor"
>>> + depends on CPU_FREQ
>>> + sele
On Fri, Apr 1, 2016 at 7:49 PM, Steve Muckle wrote:
> On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote:
> ...
>> +config CPU_FREQ_GOV_SCHEDUTIL
>> + tristate "'schedutil' cpufreq policy governor"
>> + depends on CPU_FREQ
>> + select CPU_FREQ_GOV_ATTR_SET
>> + select IRQ_WORK
>> +
On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote:
...
> +config CPU_FREQ_GOV_SCHEDUTIL
> + tristate "'schedutil' cpufreq policy governor"
> + depends on CPU_FREQ
> + select CPU_FREQ_GOV_ATTR_SET
> + select IRQ_WORK
> + help
> + This governor makes decisions based on the uti
On Wed, Mar 30, 2016 at 04:00:24AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add a new cpufreq scaling governor, called "schedutil", that uses
> scheduler-provided CPU utilization information as input for making
> its decisions.
>
> Doing that is possible after commit 34e2c55
On Thu, Mar 31, 2016 at 02:18:33PM +0200, Rafael J. Wysocki wrote:
> On Thu, Mar 31, 2016 at 2:12 PM, Peter Zijlstra wrote:
> >
> > Ingo reminded me that the schedutil governor is part of the scheduler
> > proper and can access scheduler data because of that.
> >
> > This allows us to remove the u
On Thu, Mar 31, 2016 at 2:12 PM, Peter Zijlstra wrote:
>
> Ingo reminded me that the schedutil governor is part of the scheduler
> proper and can access scheduler data because of that.
>
> This allows us to remove the util and max arguments since only the
> schedutil governor will use those, which
Ingo reminded me that the schedutil governor is part of the scheduler
proper and can access scheduler data because of that.
This allows us to remove the util and max arguments since only the
schedutil governor will use those, which leads to some further text
reduction:
435951226 24
On 03/30/2016 10:24 AM, Rafael J. Wysocki wrote:
> On Wed, Mar 30, 2016 at 7:05 PM, Steve Muckle wrote:
>> On 03/30/2016 04:31 AM, Rafael J. Wysocki wrote:
>>> +static int sugov_limits(struct cpufreq_policy *policy)
>>> +{
>>> + struct sugov_policy *sg_policy = policy->governor_dat
On Wed, Mar 30, 2016 at 7:05 PM, Steve Muckle wrote:
> On 03/30/2016 04:31 AM, Rafael J. Wysocki wrote:
>> +static int sugov_limits(struct cpufreq_policy *policy)
>> +{
>> + struct sugov_policy *sg_policy = policy->governor_data;
>> +
>> + if (!policy->fast_switch_
On 03/30/2016 04:31 AM, Rafael J. Wysocki wrote:
>>> >> +static int sugov_limits(struct cpufreq_policy *policy)
>>> >> +{
>>> >> + struct sugov_policy *sg_policy = policy->governor_data;
>>> >> +
>>> >> + if (!policy->fast_switch_enabled) {
>>> >> + mutex_lock(&sg_policy->work_l
[cut]
> The current version of this looks good to me and takes care of all the issues
> I
> raised earlier. Thanks.
>
>> +static int sugov_limits(struct cpufreq_policy *policy)
>> +{
>> + struct sugov_policy *sg_policy = policy->governor_data;
>> +
>> + if (!policy->fast_switch_enabled) {
On 30-03-16, 04:00, Rafael J. Wysocki wrote:
> +static int sugov_init(struct cpufreq_policy *policy)
> +{
> + struct sugov_policy *sg_policy;
> + struct sugov_tunables *tunables;
> + unsigned int lat;
> + int ret = 0;
> +
> + /* State should be equivalent to EXIT */
> + if (
From: Rafael J. Wysocki
Add a new cpufreq scaling governor, called "schedutil", that uses
scheduler-provided CPU utilization information as input for making
its decisions.
Doing that is possible after commit 34e2c555f3e1 (cpufreq: Add
mechanism for registering utilization update callbacks) that
13 matches
Mail list logo
