linux-kernel - Re: [PATCH v7] sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest

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:   Fri, 10 Jun 2022 17:01:27 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Valentin Schneider <vschneid@...hat.com>,
        K Prateek Nayak <kprateek.nayak@....com>,
        aubrey.li@...ux.intel.com, efault@....de, gautham.shenoy@....com,
        linux-kernel@...r.kernel.org, mgorman@...hsingularity.net,
        mingo@...nel.org, song.bao.hua@...ilicon.com,
        srikar@...ux.vnet.ibm.com, valentin.schneider@....com
Subject: Re: [PATCH v7] sched/fair: Consider cpu affinity when allowing NUMA
 imbalance in find_idlest_group

On Fri, Jun 10, 2022 at 04:42:05PM +0200, Vincent Guittot wrote:

> The test was there to not do the computation with cpumask_and() if the
> task's affinity has not been modified so maybe it would be enough to
> test (p->nr_cpus_allowed != NR_CPUS) to check if the task's affinity
> has been modified and we have we do the cpumask_and()  and
> cpumask_weight()

Yeah, I suppose that's the best we can do. I was thinking that perhaps
some cgroup/cpuset thing is common these days, in which case pretty much
all tasks will have their affinity set through the cpuset muck, but
alas, nothing really do be done about that.