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
| ||
|
Date: Mon, 4 Jun 2018 05:59:40 -0700 From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com> To: Peter Zijlstra <peterz@...radead.org> Cc: Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Mel Gorman <mgorman@...hsingularity.net>, Rik van Riel <riel@...riel.com>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [PATCH 04/19] sched/numa: Set preferred_node based on best_cpu * Peter Zijlstra <peterz@...radead.org> [2018-06-04 14:23:36]: > OK, the above matches the description, but I'm puzzled by the remainder: > > > > > - if (ng->active_nodes > 1 && numa_is_active_node(env.dst_nid, ng)) > > - sched_setnuma(p, env.dst_nid); > > + if (nid != p->numa_preferred_nid) > > + sched_setnuma(p, nid); > > } > > That seems to entirely loose the active_node thing, or are you saying > best_cpu already includes that? (Changelog could use a little help there > I suppose) I think checking for active_nodes before calling sched_setnuma was a mistake. Before this change, we may be retaining numa_preferred_nid to be the source node while we select another node with better numa affinity to run on. So we are creating a situation where we force a thread to run on a node which is not going to be its preferred_node. So in the course of regular load balancing, this task might then be moved to set preferred_node which is actually not the preferred_node.
Powered by blists - more mailing lists