linux-kernel - Re: [Eas-dev] [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

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] [day] [month] [year] [list]

Date:   Wed, 2 Aug 2017 09:14:08 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Pavan Kondeti <pkondeti@...eaurora.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Peter Zijlstra <peterz@...radead.org>, joelaf@...gle.com,
        linux-pm@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        skannan@...eaurora.org, smuckle.linux@...il.com,
        eas-dev@...ts.linaro.org
Subject: Re: [Eas-dev] [PATCH V5 2/2] cpufreq: Process remote callbacks from
 any CPU if the platform permits

On 01-08-17, 16:30, Pavan Kondeti wrote:
> Currently sugov threads in the schedutil governor are pinned to the
> policy CPUs. schedutil can now make use of this new
> dvfs_possible_from_any_cpu flag and avoid the pinning, right?

Actually yes and it would be something as simple as below. Will send a patch for
this if no one reports any problems with this.

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 9deedd5f16a5..6ea12a8c8863 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -471,7 +471,10 @@ static int sugov_kthread_create(struct sugov_policy *sg_policy)
        }
 
        sg_policy->thread = thread;
-       kthread_bind_mask(thread, policy->related_cpus);
+
+       if (!policy->dvfs_possible_from_any_cpu)
+               kthread_bind_mask(thread, policy->related_cpus);
+
        init_irq_work(&sg_policy->irq_work, sugov_irq_work);
        mutex_init(&sg_policy->work_lock);
 

-- 
viresh