From: Michal Hocko <mhocko@suse.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
Ben Widawsky <ben.widawsky@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Feng Tang <feng.tang@intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
Mike Kravetz <mike.kravetz@oracle.com>,
Randy Dunlap <rdunlap@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>,
Dan Williams <dan.j.williams@intel.com>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [RFC PATCH] mm/mempolicy: add MPOL_PREFERRED_STRICT memory policy
Date: Thu, 14 Oct 2021 13:41:47 +0200 [thread overview]
Message-ID: <YWgXe4PxdWn++8IP@dhcp22.suse.cz> (raw)
In-Reply-To: <49514c97-c540-48ee-0b2f-3cd7bd3dfcf9@linux.ibm.com>
On Thu 14-10-21 15:58:29, Aneesh Kumar K.V wrote:
> On 10/14/21 15:08, Michal Hocko wrote:
[...]
> > Besides that it would be really great to finish the discussion about the
> > usecase before suggesting a new userspace API.
> >
>
> Application would like to hint a preferred node for allocating memory
> backing a va range and at the same time wants to avoid fallback to some set
> of nodes (in the use case I am interested don't fall back to slow memory
> nodes).
We do have means for that, right? You can set your memory policy and
then set the cpu afffinity to the node you want to allocate from
initially. You can migrate to a different cpu/node if this is not the
preferred affinity. Why is that not usable?
Also think about extensibility. Say I want to allocate from a set of
nodes first before falling back to the rest of the nodemask? If you want
to add a new API then think of other potential usecases.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-10-14 11:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 9:45 [RFC PATCH] mm/mempolicy: add MPOL_PREFERRED_STRICT memory policy Aneesh Kumar K.V
2021-10-13 10:42 ` Michal Hocko
2021-10-13 10:48 ` Michal Hocko
2021-10-13 12:35 ` Aneesh Kumar K.V
2021-10-13 12:50 ` Michal Hocko
2021-10-13 12:58 ` Aneesh Kumar K.V
2021-10-13 13:07 ` Michal Hocko
2021-10-13 13:10 ` Aneesh Kumar K.V
2021-10-13 14:22 ` Michal Hocko
2021-10-13 13:57 ` Aneesh Kumar K.V
2021-10-13 14:26 ` Michal Hocko
2021-10-13 13:16 ` Andi Kleen
2021-10-13 13:23 ` Aneesh Kumar K.V
2021-10-13 14:21 ` Michal Hocko
2021-10-14 9:30 ` Aneesh Kumar K.V
2021-10-14 9:38 ` Michal Hocko
2021-10-14 10:28 ` Aneesh Kumar K.V
2021-10-14 11:41 ` Michal Hocko [this message]
2021-10-14 13:29 ` Aneesh Kumar K.V
2021-10-14 14:56 ` Michal Hocko
2021-10-14 15:50 ` Aneesh Kumar K.V
2021-10-19 9:38 ` Michal Hocko
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=YWgXe4PxdWn++8IP@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=ben.widawsky@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=feng.tang@intel.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mike.kravetz@oracle.com \
--cc=rdunlap@infradead.org \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.