LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: ligang.bdlg@bytedance.com
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, ben.widawsky@intel.com,
	dave.hansen@linux.intel.com
Subject: Re: [PATCH v7 0/5] Introduce multi-preference mempolicy
Date: Wed, 1 Dec 2021 13:33:13 +0800	[thread overview]
Message-ID: <20211201053313.GB14778@shbuild999.sh.intel.com> (raw)
In-Reply-To: <b0d1f682-6868-c5f6-631c-2da93ee2b479@bytedance.com>

Hi Gang,

On Wed, Dec 01, 2021 at 11:09:18AM +0800, Gang Li wrote:
> Hi Feng:
> 
> I am a little confused:
> We have `MPOL_PREFERRED`, why you introduce `MPOL_PREFERRED_MANY` instead of
> making `MPOL_PREFERRED` support multiple preferred nodes?

Cc Ben and Dave.

Actually in the end of this cover letter, there is some explaination
about it, qutoed here:

"
In v1, Andi Kleen brought up reusing MPOL_PREFERRED as the mode for the API.
There wasn't consensus around this, so I've left the existing API as it was. I'm
open to more feedback here, but my slight preference is to use a new API as it
ensures if people are using it, they are entirely aware of what they're doing
and not accidentally misusing the old interface. (In a similar way to how
MPOL_LOCAL was introduced).

In v1, Michal also brought up renaming this MPOL_PREFERRED_MASK. I'm equally
fine with that change, but I hadn't heard much emphatic support for one way or
another, so I've left that too.
"

Ben made this as he initiated the patchset, and I agree this can keep
the API consistent for user . Also at that time, there was another
factor that policy MPOL_PREFERRED and MPOL_LOCAL were coupled tightly
together. 

Thanks,
Feng



      reply	other threads:[~2021-12-01  5:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03  5:59 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
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 [this message]

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=20211201053313.GB14778@shbuild999.sh.intel.com \
    --to=feng.tang@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=ligang.bdlg@bytedance.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --subject='Re: [PATCH v7 0/5] Introduce multi-preference mempolicy' \
    /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

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).