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
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
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
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
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
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
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.
> >>
>
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
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
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
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
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
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
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
14 matches
Mail list logo