lkml.org 
[lkml]   [2018]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"
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?

> 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

\
 
 \ /
  Last update: 2018-05-08 12:35    [W:0.107 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site