linux-kernel - Re: [PATCH v4] sched/freq: move call to cpufreq_update

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]

Message-ID: <20191115130144.GA4097@hirez.programming.kicks-ass.net>
Date:   Fri, 15 Nov 2019 14:01:44 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mel Gorman <mgorman@...e.de>,
        Doug Smythies <dsmythies@...us.net>,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Sargun Dhillon <sargun@...gun.me>, Tejun Heo <tj@...nel.org>,
        Xie XiuQi <xiexiuqi@...wei.com>, xiezhipeng1@...wei.com,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH v4] sched/freq: move call to cpufreq_update_util

On Fri, Nov 15, 2019 at 12:03:31PM +0100, Vincent Guittot wrote:

> This patch does 2 things:
> - fix the spurious call to cpufreq just before attaching a task

Right, so that one doesn't concern me too much.

> - make sure cpufreq is still called when cfs is 0 but not irq/rt or dl

But per the rq->has_blocked_load logic we would mostly stop sending
events once we reach all 0s.

Now, most of those updates will be through _nohz_idle_balance() ->
update_nohz_stats(), which are remote, which means intel_pstate is
ignoring them anyway.

Now the _nohz_idle_balance() -> update_blocked_averages() thing runs
local, and that will update the one random idle CPU we picked to run
nohz balance, but all others will be left where they were.

So why does intel_pstate care... Esp. on SKL+ with per-core P state this
is of dubious value.

Also, and maybe I should go read back, why do we care what the P state
is when we're mostly in C states anyway? These are all idle CPUs,
otherwise we wouldkn't be running update_blocked_averages() on them
anyway.

Much confusion..