linux-kernel - Re: [PATCH] sched/eas: Don't update misfit status if the task is pinned

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]

Message-ID: <20210120115739.ohe4l2c3ed72suk3@e107158-lin>
Date:   Wed, 20 Jan 2021 11:57:39 +0000
From:   Qais Yousef <qais.yousef@....com>
To:     Quentin Perret <qperret@...gle.com>
Cc:     "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org,
        Valentin Schneider <valentin.schneider@....com>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is
 pinned

On 01/19/21 17:50, Quentin Perret wrote:
> On Tuesday 19 Jan 2021 at 17:42:44 (+0000), Qais Yousef wrote:
> > Hmm IIUC you want to still tag it as misfit so it'll be balanced within the
> > little cores in case there's another core with more spare capacity, right?
> 
> Well yes but that's just a special case. But even you have big CPUs in
> the affinity mask, you may find that the task fits on none of the CPUs
> because they're currently under pressure. But in this case, you may
> still want to mark the task as misfit because being under pressure may
> be a relatively transient state.

Okay. So your thoughts are that if the utilization is above capacity_orig_of()
then marking it as misfit is meaningless (taking into account the cpus it is
affined to). Which I agree with. But if it is less than capacity_orig_of() but
doesn't fit because of pressure ie:

	util <= capacity_orig_of(cpu) && util > capacity_of(cpu)

then we should mark it as misfit as it currently does. I think this makes sense
too. There's the margin to consider in the mix here too. And util clamp
effects. And the fact this gets called from pick_next_task_fair() which is
a hot path :-)

Unless someone else beats me to it, I'll send a patch eventually :-)

Thanks

--
Qais Yousef