Linux CXL
 help / color / mirror / Atom feed
* [RFC PATCH v2 0/4] mm/mempolicy: get/set_mempolicy2 syscalls
@ 2023-10-03  0:21 Gregory Price
  2023-10-03  0:21 ` [RFC PATCH v2 4/4] mm/mempolicy: implement a weighted-interleave Gregory Price
  0 siblings, 1 reply; 4+ messages in thread
From: Gregory Price @ 2023-10-03  0:21 UTC (permalink / raw)
  To: linux-mm
  Cc: linux-kernel, linux-arch, linux-api, linux-cxl, luto, tglx, mingo,
	bp, dave.hansen, hpa, arnd, akpm, x86, Gregory Price

v2: style updates, weighted-interleave, rename partial-interleave to
    preferred-interleave, variety of bug fixes.

---

This patch set is a proposal for set_mempolicy2 and get_mempolicy2
system calls.  This is an extension to the existing mempolicy
syscalls that allow for a more extensible mempolicy interface and
new, complex memory policies.

This RFC is broken into 4 patches for discussion:

  1) A refactor of do_set_mempolicy that allows code reuse for
     the new syscalls when replacing the task mempolicy.

  2) The implementation of get_mempolicy2 and set_mempolicy2 which
     includes a new uapi type: "struct mempolicy_args" and denotes
     the original mempolicies as "legacy". This allows the existing
     policies to be routed through the original interface.

     (note: only implemented on x86 at this time, though can be
      hacked into other architectures somewhat trivially)

  3) The implementation of "preferred-interleave", a policy which
     applies a weight to the local node while interleaving.

  4) The implementation of "weighted-interleave", a policy which
     applies weights to all enabled nodes while interleaving.

  x) Future Updates: ktest, numactl, and man page updates


Besides the obvious proposal of extending the mempolicy subsystem for
new policies, the core proposal is the addition of the new uapi type
"struct mempolicy". In this proposal, the get and set interfaces use
the same structure, and some fields may be ignored depending on the
requested operation.

This sample implementation of get_mempolicy allows for the retrieval
of all information that would have previously required multiple calls
to get_mempolicy, and implements an area for per-policy information.

This allows for future extensibility, and would avoid the need for
additional syscalls in the future.

struct mempolicy_args {
  unsigned short mode;
  unsigned long *nodemask;
  unsigned long maxnode;
  unsigned short flags;
  struct {
        /* Memory allowed */
        struct {
                unsigned long maxnode;
                unsigned long *nodemask;
        } allowed;
        /* Address information */
        struct {
                unsigned long addr;
                unsigned long node;
                unsigned short mode;
                unsigned short flags;
        } addr;
  } get;
  union {
    /* Interleave */
    struct {
      unsigned long next_node; /* get only */
    } interleave;
    /* Preferred Interleave */
    struct {
      unsigned long weight;  /* get and set */
      unsigned long next_node; /* get only */
    } pil;
    /* Weighted Interleave */
    struct {
      unsigned long next_node; /* get only */
      unsigned char *weight; /* get and set */
    } wil;
  };
};

In the third and fourth patch, we implement preferred and weighted
interleave policies (respectively), which could not be implemented
with the existing syscalls.

We extend the internal mempolicy structure to include to include
a new union area which can be used to host complex policy data.

Example:
union {
  /* Preferred Interleave: Allocate local count, then interleave */
  struct {
    int weight;
    int count;
  } pil;
  /* Weighted Interleave */
  struct {
    unsigned int il_weight;
    unsigned char cur_weight;
    unsigned char weights[MAX_NUMNODES];
  } wil;
};


Summary of Preferred Interleave:
================================
nodeset=0,1,2
interval=3
cpunode=0

The preferred node (cpunode) is the "preferred" node on which [weight]
allocations are made before an interleave occurs.

Over 10 consecutive allocations, the following nodes will be selected:
[0,0,0,1,2,0,0,0,1,2]

In this example, there is a 60%/20%/20% distribution of memory across
the node set.

This is a useful strategy if the goal is an even distribution of
memory across all non-local nodes for the purpose of bandwidth AND
task-node migrations are a possibility.  In this case, the weight
applies to whatever the local node happens to be at the time of the
interleave, rather than a static node weight.


Summary of Weighted Interleave:
===============================

The weighted-interleave mempolicy implements weights per-node
which are used to distribute memory while interleaving.

For example:
nodes: 0,1,2
weights: 5,3,2

Over 10 consecutive allocations, the following nodes will be selected:
[0,0,0,0,0,1,1,1,2,2]

If a node is enabled, the minimum weight is 1. If an enabled node
ends up with a weight of 0 (cgroup updates can cause a runtime
recalculation) a minimum of 1 is applied during interleave.

This is a useful strategy if the goal is a non-even distribution of
memory across a variety of nodes AND task-node migrations are NOT
expected to occur (or the weights are approximately the same,
relationally from all possible target nodes).

This is because "Thread A" with weights set for best performance
from the perspective of "Socket 0" may have a less-than-optimal
interleave strategy if "Thread A" is migrated to "Socket 1". In
this scenario, the bandwidth and latency attributes of each node
will have changed, as will the local node.

In the above example, a thread migrating from node 0 to node 1 will
cause most of its memory to be allocated on remote nodes, which is
less than optimal.


Some notes for discussion
=========================
0) Why?

  In the coming age of CXL and a many-numa-node system with memory
  hosted on the PCIe bus, new memory policies are likely to be
  beneficial to experiment with and ultimately implement new
  allocation-time placement policies.

  Presently, much focus is placed on memory-usage monitoring and data
  migration, but these methods steal performance to accomplish what
  could be optimized for up-front.  For example, if maximizing bandwith
  is preferable, then a statistical distribution of memory can be
  calculated fairly easily based on task location..

  Getting a fair approximation of distribution at allocation can help
  reduce the migration load required after-the fact.  This is the
  intent of the included preferred-interleave example, which allows for
  an approximate distribution of memory, where the local node is still
  the preferred location for the majority of memory.

1) Maybe this should be a set of sysfs interfaces?

  This would involve adding a /proc/pid/mempolicy interface that
  allows for external processes to interrogate and change the
  mempolicy of running processes. This would be a fundamental
  change to the mempolicy subsystem.

  I attempted this, but eventually came to the conclusion that it
  would require a much more radical re-write of mempolicy.c code
  due concurrency issues.

  Notably, mempolicy.c is very "current"--centric, and is not well
  designed for runtime changes to nodemask (and, subsequently, the
  new weights added to struct mempolicy).

  I avoided that for this RFC as it seemed far more radical than
  proposing a set/get_mempolicy2 interface.  Though technically it
  could be done.

2) Why not do this in cgroups or memtier?

  Both have the issue of functionally being a "global" setting,
  in the sense that cgroups/memtier implemented weights would
  produce poor results on processes whose threads span multiple
  sockets (or on a thread migration).

  Consider the following scenario:

  Node 0 - Socket 0 DRAM
  Node 1 - Socket 1 DRAM
  Node 2 - Socket 0 local CXL
  Node 3 - Socket 1 local CXL
  Weights:
    [0:4, 1:2, 2:2, 3:1]

  The "Tiers" in this case are essentially [0, 1-2, 3]

  We have 2 tasks in our cgroup:
  Thread A - socket 0
  Thread B - socket 1

  In this scenario, Thread B will have a very poor distribution of
  memory, with most of its memory landing on a remote-socket.

  Instead, it's preferable for workloads to stick to a single socket
  where possible, and future work will need to be done to determine
  how to handle workloads which span sockets.  Due to the above
  mentioned issues with concurrency, this may be quite some time.

  In the meantime, there is user for weights to be carried per-task.

  For migrations:

  Weights could be recalculated based on the new location of the
  task. This recalculation of weights is not included in this
  patch set, but could be done as an extension to weighted
  interleave, where a thread that detects it has been migrated
  works with memtier.c to adjust its weights internally.

  So basically even if you implement these things in cgroups/memtier,
  you still require per-task information (local node) to adjust the
  weights.  My proposal: Just do it in mempolicy and use things like
  cgroups/memtier to enrich that implementation, rather than the other
  way around.

3) Do we need this level extensibility?

   Presently the ability to dictate allocation-time placement is
   limited to a few primitive mechanisms:

     1) existing mempolicy, and those that can be implemented using
        the existing interface.
     2) numa-aware applications, requiring code changes.
     3) LDPRELOAD methods, which have compability issues.

   For the sake of compatibility, being able to extend numactl to
   include newer, more complex policies would be beneficial.

Gregory Price (4):
  mm/mempolicy: refactor do_set_mempolicy for code re-use
  mm/mempolicy: Implement set_mempolicy2 and get_mempolicy2 syscalls
  mm/mempolicy: implement a preferred-interleave mempolicy
  mm/mempolicy: implement a weighted-interleave mempolicy

 arch/x86/entry/syscalls/syscall_32.tbl |   2 +
 arch/x86/entry/syscalls/syscall_64.tbl |   2 +
 include/linux/mempolicy.h              |  14 +
 include/linux/syscalls.h               |   4 +
 include/uapi/asm-generic/unistd.h      |  10 +-
 include/uapi/linux/mempolicy.h         |  41 ++
 mm/mempolicy.c                         | 688 ++++++++++++++++++++++++-
 7 files changed, 741 insertions(+), 20 deletions(-)

-- 
2.39.1


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-07  8:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CGME20231206080944epcms2p76ebb230b9f4595f5cfcd2531d67ab3ce@epcms2p7>
2023-12-06  8:09 ` [RFC PATCH v2 4/4] mm/mempolicy: implement a weighted-interleave Seungjun Ha
2023-12-06 17:02   ` Gregory Price
2023-12-07  8:52     ` Seungjun Ha
2023-10-03  0:21 [RFC PATCH v2 0/4] mm/mempolicy: get/set_mempolicy2 syscalls Gregory Price
2023-10-03  0:21 ` [RFC PATCH v2 4/4] mm/mempolicy: implement a weighted-interleave Gregory Price

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox