On 20-06-22 13:54:30, 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? > > Is there any indication that this is actually the case? > > If not I would prefer to just extend the semantics of the existing MPOL_PREFERRED. > > Even if there was such an legacy application any legacy behavior changes > are likely not fatal, because preferred is only a hint anyways. Anybody > who really requires the right nodes would use _BIND. > > -Andi > It does break ABI in a sense as the existing MPOL_PREFERRED does in fact specify it should fail if more than one node is specified. A decent compromise might be to add a new flag to be used with MPOL_PREFERRED, hinting you want like a v2 version of the interface. Honestly, I don't care either way. I inherited it from Dave Hansen, and I can only guess at his motivation. Perhaps more valuable to consider was #3 alternative in the snipped part of the cover letter: > 3. Create flags or new modes that helps with some ordering. This offers both a > friendlier API as well as a solution for more customized usage. It's unknown > if it's worth the complexity to support this. Here is sample code for how > this might work: > > // Default > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_SOCKET, NULL, 0); > // which is the same as > set_mempolicy(MPOL_DEFAULT, NULL, 0); > > // The Hare > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE, NULL, 0); > > // The Tortoise > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE_REV, NULL, 0); > > // Prefer the fast memory of the first two sockets > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE, -1, 2); > > // Prefer specific nodes for some something wacky > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE_CUSTOM, 0x17c, 1024);
