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: <20180508122040.GE19168@localhost.localdomain>
Date:   Tue, 8 May 2018 14:20:40 +0200
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Quentin Perret <quentin.perret@....com>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        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>,
        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 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. :/