Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1725749 > unrolled thread

[PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

Back to article view | Back to linux.kernel

Contents

  [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps Joel Fernandes <joelaf@google.com> - 2017-09-03 22:20 +0200
    Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on  rq that sleeps Joel Fernandes <joelaf@google.com> - 2017-09-07 18:20 +0200
      Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on  rq that sleeps Steve Muckle <smuckle@google.com> - 2017-09-07 20:20 +0200
        Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on  rq that sleeps Joel Fernandes <joelaf@google.com> - 2017-09-07 21:00 +0200

#1725749 — [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

These patches are just a repost of [1] and [2] with a cover letter for more
history and backround. On the Pixel product we carry a similar path which was
also posted some time ago to LKML [3] [4] however that patch was for schedfreq
governor (which isn't upstream). For schedutil which is upstream and currently
used on our future products, we go through the cpufreq update hooks and this
patch is adapted for this usecase.

[1] https://patchwork.kernel.org/patch/9910019/
[2] https://patchwork.kernel.org/patch/9910017/
[3] https://patchwork.kernel.org/patch/8385861/
[4] https://lwn.net/Articles/676886/

Joel Fernandes (2):
  Revert "sched/fair: Drop always true parameter of
    update_cfs_rq_load_avg()"
  sched/fair: Skip frequency update if CPU about to idle

 kernel/sched/fair.c  | 38 +++++++++++++++++++++++++++++---------
 kernel/sched/sched.h |  1 +
 2 files changed, 30 insertions(+), 9 deletions(-)

Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@arm.com>
Cc: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: kernel-team@android.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
-- 
2.14.1.581.gf28d330327-goog

[toc] | [next] | [standalone]

#1728292 — Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

On Sun, Sep 3, 2017 at 1:15 PM, Joel Fernandes <joelaf@google.com> wrote:
> These patches are just a repost of [1] and [2] with a cover letter for more
> history and backround. On the Pixel product we carry a similar path which was
> also posted some time ago to LKML [3] [4] however that patch was for schedfreq
> governor (which isn't upstream). For schedutil which is upstream and currently
> used on our future products, we go through the cpufreq update hooks and this
> patch is adapted for this usecase.
>
> [1] https://patchwork.kernel.org/patch/9910019/
> [2] https://patchwork.kernel.org/patch/9910017/
> [3] https://patchwork.kernel.org/patch/8385861/
> [4] https://lwn.net/Articles/676886/
>

Hi,

I'm planning to rebase this series on Linus's master and post it
again, but just checking any thoughts about it?

Just to add more context, the reason for not updating the frequency:

- When a last dequeue of a sleeping task happens, it is sufficient to
update utilization without updating the frequency because if other
CPUs are busy then their updates will consider the utilization of the
idle CPU in the shared policy unless sufficient time has passed.

- If the last dequeue of a sleeping task happens while all other CPUs
in the cluster are idle, then the cluster will likely enter
cluster-idle soon.

Could you let me know your opinions on this series?

thanks,

-Joel


[..]

[toc] | [prev] | [next] | [standalone]

#1728362 — Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

On 09/07/2017 09:14 AM, Joel Fernandes wrote:
> I'm planning to rebase this series on Linus's master and post it
> again, but just checking any thoughts about it?
> 
> Just to add more context, the reason for not updating the frequency:
> 
> - When a last dequeue of a sleeping task happens, it is sufficient to
> update utilization without updating the frequency because if other
> CPUs are busy then their updates will consider the utilization of the
> idle CPU in the shared policy unless sufficient time has passed.
> 
> - If the last dequeue of a sleeping task happens while all other CPUs
> in the cluster are idle, then the cluster will likely enter
> cluster-idle soon.

To clarify - when you say "last dequeue of a sleeping task happens" 
above, you're referring to the dequeue of the last task running on the 
CPU, correct? I.e. the CPU is about to go idle?

It's been a while since I've looked at this area so would like to hold 
off for a rebased version to review in further detail. But I think the 
concept is valid.

thanks,
steve

[toc] | [prev] | [next] | [standalone]

#1728392 — Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

Hi Steve,

On Thu, Sep 7, 2017 at 11:10 AM, Steve Muckle <smuckle@google.com> wrote:
> On 09/07/2017 09:14 AM, Joel Fernandes wrote:
>>
>> I'm planning to rebase this series on Linus's master and post it
>> again, but just checking any thoughts about it?
>>
>> Just to add more context, the reason for not updating the frequency:
>>
>> - When a last dequeue of a sleeping task happens, it is sufficient to
>> update utilization without updating the frequency because if other
>> CPUs are busy then their updates will consider the utilization of the
>> idle CPU in the shared policy unless sufficient time has passed.
>>
>> - If the last dequeue of a sleeping task happens while all other CPUs
>> in the cluster are idle, then the cluster will likely enter
>> cluster-idle soon.
>
>
> To clarify - when you say "last dequeue of a sleeping task happens" above,
> you're referring to the dequeue of the last task running on the CPU,
> correct? I.e. the CPU is about to go idle?

Yes that's right, sorry for my poor choice of words. I am referring to
dequeue of a task that is DEQUEUE_SLEEP and is the only task on the
RQ.

> It's been a while since I've looked at this area so would like to hold off
> for a rebased version to review in further detail. But I think the concept
> is valid.

Sure and thanks for making time for the review!

-Joel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web