On 6/22/20 1:54 PM, Andi Kleen wrote: > On Fri, Jun 19, 2020 at 09:24:07AM -0700, Ben Widawsky wrote: >> This patch series introduces the concept of the MPOL_PREFERRED_MANY mempolicy. > So the reason for having a new policy is that you're worried some legacy > application passes multiple nodes to MPOL_PREFERRED, where all but the > first would be currently ignored. Is that right? It's one thing if our internal implementation threw away all but the first preferred node silently. We do that, but we also go pretty far to blab in the manpage to solidify this behavior: If nodemask specifies more than one node ID, the first node in the mask will be selected as the preferred node. I think it's dangerous to go and actively break that promise. It means that newer apps will silently not get the behavior they ask for if they run on an old kernel. We also promise: The kernel will try to allocate pages from this node first and fall back to "near by" nodes if the preferred node is low on free memory. A user could legitimately say that the kernel breaks this promise if they passed multiple preferred nodes, one of them had lots of free memory, and that node node was not preferred.
