linux-kernel - Re: [PATCH RFC RESEND v2 0/2] Prevent cpufreq update for only task on rq that sleeps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Sep 2017 09:14:00 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     Joel Fernandes <joelaf@...gle.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Len Brown <lenb@...nel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@....com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Steve Muckle <smuckle@...gle.com>, kernel-team@...roid.com
Subject: 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@...gle.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


[..]