linux-kernel - Re: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190726065739.xjvyvqpkb3o6m4ty@vireshk-i7>
Date:   Fri, 26 Jul 2019 12:27:39 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Doug Smythies <dsmythies@...us.net>
Cc:     "'Rafael J. Wysocki'" <rafael@...nel.org>,
        'Rafael Wysocki' <rjw@...ysocki.net>,
        'Ingo Molnar' <mingo@...hat.com>,
        'Peter Zijlstra' <peterz@...radead.org>,
        'Linux PM' <linux-pm@...r.kernel.org>,
        'Vincent Guittot' <vincent.guittot@...aro.org>,
        'Joel Fernandes' <joel@...lfernandes.org>,
        "'v4 . 18+'" <stable@...r.kernel.org>,
        'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cpufreq: schedutil: Don't skip freq update when limits
 change

On 25-07-19, 08:20, Doug Smythies wrote:
> I tried the patch ("patch2"). It did not fix the issue.
> 
> To summarize, all kernel 5.2 based, all intel_cpufreq driver and schedutil governor:
> 
> Test: Does a busy system respond to maximum CPU clock frequency reduction?
> 
> stock, unaltered: No.
> revert ecd2884291261e3fddbc7651ee11a20d596bb514: Yes
> viresh patch: No.
> fast_switch edit: No.
> viresh patch2: No.

Hmm, so I tried to reproduce your setup on my ARM board.
- booted only with CPU0 so I hit the sugov_update_single() routine
- And applied below diff to make CPU look permanently busy:

-------------------------8<-------------------------
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 2f382b0959e5..afb47490e5dc 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -121,6 +121,7 @@ static void sugov_fast_switch(struct sugov_policy *sg_policy, u64 time,
        if (!sugov_update_next_freq(sg_policy, time, next_freq))
                return;
 
+       pr_info("%s: %d: %u\n", __func__, __LINE__, freq);
        next_freq = cpufreq_driver_fast_switch(policy, next_freq);
        if (!next_freq)
                return;
@@ -424,14 +425,10 @@ static unsigned long sugov_iowait_apply(struct sugov_cpu *sg_cpu, u64 time,
 #ifdef CONFIG_NO_HZ_COMMON
 static bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu)
 {
-       unsigned long idle_calls = tick_nohz_get_idle_calls_cpu(sg_cpu->cpu);
-       bool ret = idle_calls == sg_cpu->saved_idle_calls;
-
-       sg_cpu->saved_idle_calls = idle_calls;
-       return ret;
+       return true;
 }
 #else
-static inline bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) { return false; }
+static inline bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) { return true; }
 #endif /* CONFIG_NO_HZ_COMMON */
 
 /*
@@ -565,6 +562,7 @@ static void sugov_work(struct kthread_work *work)
        sg_policy->work_in_progress = false;
        raw_spin_unlock_irqrestore(&sg_policy->update_lock, flags);
 
+       pr_info("%s: %d: %u\n", __func__, __LINE__, freq);
        mutex_lock(&sg_policy->work_lock);
        __cpufreq_driver_target(sg_policy->policy, freq, CPUFREQ_RELATION_L);
        mutex_unlock(&sg_policy->work_lock);

-------------------------8<-------------------------

Now, the frequency never gets down and so gets set to the maximum
possible after a bit.

- Then I did:

echo <any-low-freq-value> > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq

Without my patch applied:
        The print never gets printed and so frequency doesn't go down.

With my patch applied:
        The print gets printed immediately from sugov_work() and so
        the frequency reduces.

Can you try with this diff along with my Patch2 ? I suspect there may
be something wrong with the intel_cpufreq driver as the patch fixes
the only path we have in the schedutil governor which takes busyness
of a CPU into account.

-- 
viresh