Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-20 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 1:54 PM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:39 PM, Rafael J. Wysocki wrote: >> On Fri, May 20, 2016 at 2:46 AM, Rafael J. Wysocki wrote: >>> On Fri, May 20, 2016 at 2:40 AM, Steve Muckle >>> wrote: On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-20 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 1:39 PM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 2:46 AM, Rafael J. Wysocki wrote: >> On Fri, May 20, 2016 at 2:40 AM, Steve Muckle >> wrote: >>> On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael J. Wysocki wrote: Also I think that it would be good to avoi

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-20 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 2:46 AM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 2:40 AM, Steve Muckle wrote: >> On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael J. Wysocki wrote: >>> Also I think that it would be good to avoid walking the frequency >>> table twice in case we end up wanting to

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 2:37 AM, Steve Muckle wrote: > On Fri, May 20, 2016 at 02:24:19AM +0200, Rafael J. Wysocki wrote: >> On Fri, May 20, 2016 at 1:34 AM, Steve Muckle >> wrote: >> > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >> >> But anyway this change again seems to

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 2:40 AM, Steve Muckle wrote: > On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael J. Wysocki wrote: >> Also I think that it would be good to avoid walking the frequency >> table twice in case we end up wanting to update the frequency after >> all. With the [4/5] we'd do it o

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Steve Muckle
On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael J. Wysocki wrote: > Also I think that it would be good to avoid walking the frequency > table twice in case we end up wanting to update the frequency after > all. With the [4/5] we'd do it once in get_next_freq() and then once > more in cpufreq_driv

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Steve Muckle
On Fri, May 20, 2016 at 02:24:19AM +0200, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > >> But anyway this change again seems to be an optimization that might be > >> done later to me. > >> >

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 2:24 AM, Rafael J. Wysocki wrote: > On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: >> On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >>> But anyway this change again seems to be an optimization that might be >>> done later to me. >>> >>> I guess t

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Rafael J. Wysocki
On Fri, May 20, 2016 at 1:34 AM, Steve Muckle wrote: > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: >> But anyway this change again seems to be an optimization that might be >> done later to me. >> >> I guess there are many things that might be optimized in schedutil, >> but

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Steve Muckle
On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote: > But anyway this change again seems to be an optimization that might be > done later to me. > > I guess there are many things that might be optimized in schedutil, > but I'd prefer to address one item at a time, maybe going after

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Rafael J. Wysocki
On Thu, May 19, 2016 at 9:46 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > The rate limit timestamp (last_freq_update_time) is currently advanced >> > anytime schedutil re-evaluates the

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-19 Thread Steve Muckle
On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > The rate limit timestamp (last_freq_update_time) is currently advanced > > anytime schedutil re-evaluates the policy regardless of whether the CPU > > frequency is changed

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-18 Thread Rafael J. Wysocki
On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > The rate limit timestamp (last_freq_update_time) is currently advanced > anytime schedutil re-evaluates the policy regardless of whether the CPU > frequency is changed or not. This means that utilization updates which > have no effect can caus

[PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

2016-05-09 Thread Steve Muckle
The rate limit timestamp (last_freq_update_time) is currently advanced anytime schedutil re-evaluates the policy regardless of whether the CPU frequency is changed or not. This means that utilization updates which have no effect can cause much more significant utilization updates (which require a l