LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Michal Hocko <firstname.lastname@example.org> To: Feng Tang <email@example.com> Cc: firstname.lastname@example.org, Andrew Morton <email@example.com>, David Rientjes <firstname.lastname@example.org>, Dave Hansen <email@example.com>, Ben Widawsky <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Andrea Arcangeli <email@example.com>, Mel Gorman <firstname.lastname@example.org>, Mike Kravetz <email@example.com>, Randy Dunlap <firstname.lastname@example.org>, Vlastimil Babka <email@example.com>, Andi Kleen <firstname.lastname@example.org>, Dan Williams <email@example.com>, firstname.lastname@example.org, Dave Hansen <email@example.com> Subject: Re: [PATCH v7 1/5] mm/mempolicy: Add MPOL_PREFERRED_MANY for multiple preferred nodes Date: Fri, 6 Aug 2021 15:28:12 +0200 [thread overview] Message-ID: <YQ047Gcakj2scjNK@dhcp22.suse.cz> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue 03-08-21 13:59:18, Feng Tang wrote: > From: Dave Hansen <email@example.com> > > The NUMA APIs currently allow passing in a "preferred node" as a > single bit set in a nodemask. If more than one bit it set, bits > after the first are ignored. > > This single node is generally OK for location-based NUMA where > memory being allocated will eventually be operated on by a single > CPU. However, in systems with multiple memory types, folks want > to target a *type* of memory instead of a location. For instance, > someone might want some high-bandwidth memory but do not care about > the CPU next to which it is allocated. Or, they want a cheap, > high capacity allocation and want to target all NUMA nodes which > have persistent memory in volatile mode. In both of these cases, > the application wants to target a *set* of nodes, but does not > want strict MPOL_BIND behavior as that could lead to OOM killer or > SIGSEGV. > > So add MPOL_PREFERRED_MANY policy to support the multiple preferred > nodes requirement. This is not a pie-in-the-sky dream for an API. > This was a response to a specific ask of more than one group at Intel. > Specifically: > > 1. There are existing libraries that target memory types such as > https://github.com/memkind/memkind. These are known to suffer > from SIGSEGV's when memory is low on targeted memory "kinds" that > span more than one node. The MCDRAM on a Xeon Phi in "Cluster on > Die" mode is an example of this. > 2. Volatile-use persistent memory users want to have a memory policy > which is targeted at either "cheap and slow" (PMEM) or "expensive and > fast" (DRAM). However, they do not want to experience allocation > failures when the targeted type is unavailable. > 3. Allocate-then-run. Generally, we let the process scheduler decide > on which physical CPU to run a task. That location provides a > default allocation policy, and memory availability is not generally > considered when placing tasks. For situations where memory is > valuable and constrained, some users want to allocate memory first, > *then* allocate close compute resources to the allocation. This is > the reverse of the normal (CPU) model. Accelerators such as GPUs > that operate on core-mm-managed memory are interested in this model. > > A check is added in sanitize_mpol_flags() to not permit 'prefer_many' > policy to be used for now, and will be removed in later patch after all > implementations for 'prefer_many' are ready, as suggested by Michal Hocko. > > [Michal Hocko: suggest to refine policy_node/policy_nodemask handling] > Link: https://firstname.lastname@example.org > Co-developed-by: Ben Widawsky <email@example.com> > Signed-off-by: Ben Widawsky <firstname.lastname@example.org> > Signed-off-by: Dave Hansen <email@example.com> > Signed-off-by: Feng Tang <firstname.lastname@example.org> Acked-by: Michal Hocko <email@example.com> Thanks! -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2021-08-06 13:28 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-03 5:59 [PATCH v7 0/5] Introduce multi-preference mempolicy Feng Tang 2021-08-03 5:59 ` [PATCH v7 1/5] mm/mempolicy: Add MPOL_PREFERRED_MANY for multiple preferred nodes Feng Tang 2021-08-06 13:27 ` Michal Hocko 2021-08-06 13:28 ` Michal Hocko [this message] 2021-08-03 5:59 ` [PATCH v7 2/5] mm/memplicy: add page allocation function for MPOL_PREFERRED_MANY policy Feng Tang 2021-08-06 13:29 ` Michal Hocko 2021-08-03 5:59 ` [PATCH v7 3/5] mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY Feng Tang 2021-08-06 13:35 ` Michal Hocko 2021-08-09 2:44 ` Feng Tang 2021-08-09 8:41 ` Michal Hocko 2021-08-09 12:37 ` Feng Tang 2021-08-09 13:19 ` Michal Hocko 2021-08-10 8:50 ` Feng Tang 2021-08-10 21:35 ` Hugh Dickins 2021-08-11 1:37 ` Feng Tang 2021-08-10 20:06 ` [PATCH] mm/hugetlb: Initialize page to NULL in alloc_buddy_huge_page_with_mpol() Nathan Chancellor 2021-08-11 1:21 ` Feng Tang 2021-08-03 5:59 ` [PATCH v7 4/5] mm/mempolicy: Advertise new MPOL_PREFERRED_MANY Feng Tang 2021-08-03 5:59 ` [PATCH v7 5/5] mm/mempolicy: unify the create() func for bind/interleave/prefer-many policies Feng Tang 2021-12-01 3:09 ` [PATCH v7 0/5] Introduce multi-preference mempolicy Gang Li 2021-12-01 5:33 ` Feng Tang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YQ047Gcakj2scjNK@dhcp22.suse.cz \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).