linux-kernel - Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related

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: <20180508110003.GC3752@e108498-lin.cambridge.arm.com>
Date:   Tue, 8 May 2018 12:00:03 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Dietmar Eggemann <dietmar.eggemann@....com>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, linux-pm@...r.kernel.org,
        Pavan Kondeti <pkondeti@...eaurora.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Patrick Bellasi <patrick.bellasi@....com>
Subject: Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to
 related_cpus unnecessarily"

On Tuesday 08 May 2018 at 16:04:27 (+0530), Viresh Kumar wrote:
> On 08-05-18, 11:02, Quentin Perret wrote:
> > The sugov kthreads are DL tasks so they're not impacted by EAS. But even
> > if you take EAS out of the picture, those kthreads are assigned to a
> > "random" CPU at boot time and stay there forever (because that's how DL
> > works). Is this what we want ?
> 
> Okay, I didn't knew that DL threads don't migrate at all. I don't
> think that's what we want then specially for big LITTLE platforms. But
> for the rest, I don't know. Take example of Qcom krait. Each CPU has a
> separate policy, why shouldn't we allow other CPUs to run the kthread?

Right, I see your point. Now, with the current implementation, why should
we randomly force a CPU to manage the kthread of another ? IIUC deadline
should assign the kthreads to CPUs depending on the state of the system
when the task is created. So, from one boot to another, you could
theoretically end up with varying configurations, and varying power/perf
numbers.

> 
> > Looking at the commit you mention below it seems that you did the
> > testing on the old hikey which has only one cpufreq policy. Did you try
> > on other platforms as well ?
> 
> Yeah, the testing wasn't performance oriented but rather corner case
> oriented and it made sense to allow other CPUs to go update the freq
> for remote CPUs. And that's true for big LITTLE as well, the only
> question here is which CPUs we want the thread to run on.
> 
> -- 
> viresh