On Mon, Feb 8, 2016 at 1:52 PM, Rafael J. Wysocki wrote:
> On Mon, Feb 8, 2016 at 12:52 PM, Viresh Kumar wrote:
>> On 08-02-16, 03:08, Rafael J. Wysocki wrote:
>>> Moreover, update_sampling_rate() doesn't need to walk the cpu_dbs_infos,
>>> it may walk policies instead. Like after the (untested)
On Mon, Feb 8, 2016 at 12:52 PM, Viresh Kumar wrote:
> On 08-02-16, 03:08, Rafael J. Wysocki wrote:
>> Moreover, update_sampling_rate() doesn't need to walk the cpu_dbs_infos,
>> it may walk policies instead. Like after the (untested) appended patch.
>>
>> Then, if we have a governor_data_lock in
On 08-02-16, 03:08, Rafael J. Wysocki wrote:
> Moreover, update_sampling_rate() doesn't need to walk the cpu_dbs_infos,
> it may walk policies instead. Like after the (untested) appended patch.
>
> Then, if we have a governor_data_lock in struct policy, we can use that
> to protect policy_dbs whi
On Sunday, February 07, 2016 03:43:20 PM Rafael J. Wysocki wrote:
> On Sunday, February 07, 2016 02:40:40 PM Viresh Kumar wrote:
> > On 06-02-16, 00:10, Rafael J. Wysocki wrote:
> > > On Friday, February 05, 2016 08:17:56 PM Viresh Kumar wrote:
> > > > Okay, how about this then.
> > > >
> > > > We
On Sunday, February 07, 2016 02:40:40 PM Viresh Kumar wrote:
> On 06-02-16, 00:10, Rafael J. Wysocki wrote:
> > On Friday, February 05, 2016 08:17:56 PM Viresh Kumar wrote:
> > > Okay, how about this then.
> > >
> > > We do some computations here and based on them, conditionally want to
> > > upda
On 06-02-16, 00:10, Rafael J. Wysocki wrote:
> On Friday, February 05, 2016 08:17:56 PM Viresh Kumar wrote:
> > Okay, how about this then.
> >
> > We do some computations here and based on them, conditionally want to
> > update sample_delay_ns. Because there is no penalty now, in terms of
> > remo
On Friday, February 05, 2016 08:17:56 PM Viresh Kumar wrote:
> On Fri, Feb 5, 2016 at 7:06 PM, Rafael J. Wysocki wrote:
>
> >>> Index: linux-pm/drivers/cpufreq/cpufreq_ondemand.c
> >>> @@ -264,7 +260,7 @@ static void update_sampling_rate(struct
> >>> struct od_cpu_dbs_info_s *dbs_in
On Friday, February 05, 2016 02:36:54 PM Rafael J. Wysocki wrote:
> On Fri, Feb 5, 2016 at 7:50 AM, Viresh Kumar wrote:
> > Will suck some more blood, sorry about that :)
> >
> > On 05-02-16, 02:28, Rafael J. Wysocki wrote:
> >> The v3 addresses some review comments from Viresh and a couple of iss
On Fri, Feb 5, 2016 at 7:06 PM, Rafael J. Wysocki wrote:
>>> Index: linux-pm/drivers/cpufreq/cpufreq_ondemand.c
>>> @@ -264,7 +260,7 @@ static void update_sampling_rate(struct
>>> struct od_cpu_dbs_info_s *dbs_info;
>>> struct cpu_dbs_info *cdbs;
>>> stru
On Fri, Feb 5, 2016 at 7:50 AM, Viresh Kumar wrote:
> Will suck some more blood, sorry about that :)
>
> On 05-02-16, 02:28, Rafael J. Wysocki wrote:
>> The v3 addresses some review comments from Viresh and a couple of issues
>> found
>> by me. Changes from the previous version:
>> - Synchronize
Will suck some more blood, sorry about that :)
On 05-02-16, 02:28, Rafael J. Wysocki wrote:
> The v3 addresses some review comments from Viresh and a couple of issues found
> by me. Changes from the previous version:
> - Synchronize gov_cancel_work() with the (new) irq_work properly.
> - Add a co
From: Rafael J. Wysocki
Instead of using a per-CPU deferrable timer for queuing up governor
work items, register a utilization update callback that will be
invoked from the scheduler on utilization changes.
The sampling rate is still the same as what was used for the
deferrable timers and the ad
12 matches
Mail list logo
