linux-kernel - Re: [PATCH] sched: Take thermal pressure into account when determine rt fits capacity

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]

Date:   Tue, 26 Apr 2022 14:06:27 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Xuewen Yan <xuewen.yan94@...il.com>,
        Xuewen Yan <xuewen.yan@...soc.com>, dietmar.eggemann@....com,
        lukasz.luba@....com, rafael@...nel.org, viresh.kumar@...aro.org,
        mingo@...hat.com, peterz@...radead.org, rostedt@...dmis.org,
        linux-kernel@...r.kernel.org, di.shen@...soc.com
Subject: Re: [PATCH] sched: Take thermal pressure into account when determine
 rt fits capacity

On 04/26/22 12:06, Vincent Guittot wrote:
> > Wouldn't this be expensive to have 3 loops? That was my other suggestion but
> > wasn't sure the complexity was worth it. So I suggested handling the capacity
> > inversion case only.
> 
> 3 loops might be too expensive. I mainly want to make sure to
> understand what should be done to fix Xuewen case without breaking
> others. Then we can see how to optimize this in a reasonable number of
> loop

The generic solution is what I tried to outline before:

> So if we want to handle this case, then we need to ensure the search returns
> false only if
>
>         1. Thermal pressure results in real OPP to be omitted.
>         2. Another CPU that can provide this performance level is available.
>
> Otherwise we should still fit it on this CPU because it'll give us the closest
> thing to what was requested.

And we can do this in 2 ways, 3 loops as you said, or by creating a fallback
cpumask as we search so that by the end we can resolve to it if we didn't find
the best fit.

My only worry here is that Xuewen doesn't see thermal issues on mids, so
testability is a problem. This generic solution will only help with the case of
mids losing some OPPs at the top, then we can do better by selecting a big core
instead of a medium (if not in capacity inversion itself).

I *think* (and I don't feel strongly about it at all), checking for capacity
inversion and bypassing that cpu, or only then consider its thermal pressure,
is the right approach to take here until someone reports more woes due to
thermal pressure.

That said, the generic solution might not be that bad actually and I'm just
being a bit conservative. So would be good to hear what others think.

Thanks

--
Qais Yousef