linux-kernel - Re: [PATCH 1/7] sched/uclamp: Fix relationship between uclamp and migration margin

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, 2 Aug 2022 17:22:57 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Xuewen Yan <xuewen.yan94@...il.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        linux-kernel@...r.kernel.org, Wei Wang <wvw@...gle.com>,
        Jonathan JMChen <Jonathan.JMChen@...iatek.com>,
        Hank <han.lin@...iatek.com>
Subject: Re: [PATCH 1/7] sched/uclamp: Fix relationship between uclamp and
 migration margin

Hi Xuewen

On 08/01/22 10:46, Xuewen Yan wrote:
> Hi Qais
> 
> On Thu, Jul 28, 2022 at 12:25 AM Qais Yousef <qais.yousef@....com> wrote:

[...]

> > I do have a patch to add kernel doc to better explain what uclamp is. Hopefully
> > I'll send this out soon. I've been sleeping on it for a long while but too many
> > things to do, too little time :-)
> Ah, Could this patch loop me in the future? I want to learn more from
> you, Thanks!

Will do! I'll be going on holidays soon, so hopefully once I'm back I'll be
able to post it.

[...]

> > > I agree with you, but I'm still a bit concerned that such a setup will
> > > cause performance issues.
> > > As you say, may one want the background tasks running on the little
> > > cpus, he can use cpuset to control them completely.
> >
> > We are actually hoping that we can enable using uclamp_max as weak affinity
> > instead of the aggressive cpusets. But there's still a bit more work to do
> > before we can get there.
> >
> > > When there are many processes in the system, if such processes always
> > > fit small cores, do we need to consider more when load balancing?
> >
> > Oh, you're worried about packing these tasks on small cores?
> >
> > We've looked at that, and this should be hard to happen.
> >
> > EAS will always distribute tasks on max_spare_capacity cpu in the performance
> > domain. Only exception I'm aware of is if a lot of tasks wake up at the same
> > time. Then there's a chance (race) they all see the same max_spare capacity
> > before any of these tasks gets enqueue to adjust the rq->util_avg.
> >
> > Packing can't happen outside of EAS AFAICT. The default behavior of the
> > scheduler is to distribute tasks on idle cpus or based on load.
> >
> > If we're in overutilized, then select_idle_capacity() should consider the idle
> > cpus only. And in load balance in general should distribute tasks based on
> > idle/load.
> 
> Yes, you're right, I'm thinking a little bit less...Thanks!

It's complicated inter-relationship. Glad you asked! :-)


Thanks!

--
Qais Yousef