Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

[Juri Lelli <juri.lelli@redhat.com>]

On 08/05/18 12:24, Quentin Perret wrote:
> On Tuesday 08 May 2018 at 16:44:51 (+0530), Viresh Kumar wrote:
> > On 08-05-18, 12:00, Quentin Perret wrote:
> > > 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.
> > 
> > Yeah, if it is fixed at boot then there is no good reason to push it
> > to any other CPU. I agree.
> > 
> 
> To be fair, I think that DL tasks _can_ migrate, but only in special
> conditions (hotplug, or if a DL task wakes up when another DL task is
> running and things like that IIRC) but that probably doesn't matter much
> for our discussion here.

More than "special" I'd say "different" (w.r.t. CFS). DL looks at tasks
deadlines and use that info to migrate tasks around. So, it's correct
that they will currently stay on first CPU they run on if no other DL
tasks are around.

Luca's capacity(/energy) awareness stuff should change that in the
future. But that might take a while I guess. :/