All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: akpm@linux-foundation.org, muchun.song@linux.dev,
	david@redhat.com, linmiaohe@huawei.com, naoya.horiguchi@nec.com,
	mhocko@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm: hugetlb: make the hugetlb migration strategy consistent
Date: Tue, 27 Feb 2024 16:17:16 +0100	[thread overview]
Message-ID: <Zd38_AYtr9QKp-F6@localhost.localdomain> (raw)
In-Reply-To: <bdca97e6c59f1b58f09e18defac0c47d1e38f44b.1709041586.git.baolin.wang@linux.alibaba.com>

On Tue, Feb 27, 2024 at 09:52:26PM +0800, Baolin Wang wrote:

> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2567,13 +2567,38 @@ static struct folio *alloc_surplus_hugetlb_folio(struct hstate *h,
>  }
>  
>  static struct folio *alloc_migrate_hugetlb_folio(struct hstate *h, gfp_t gfp_mask,
> -				     int nid, nodemask_t *nmask)
> +				     int nid, nodemask_t *nmask, int reason)

I still dislike taking the reason argument this far, and I'd rather have
this as a boolean specifing whether we allow fallback on other nodes.
That would mean parsing the reason in alloc_migration_target().
If we don't add a new helper e.g: gfp_allow_fallback(), we can just do
it right there an opencode it with a e.g: macro etc.

Although doing it in an inline helper might help hiding these details.

That's my take on this, but let's see what others have to say.

-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2024-02-27 15:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 13:52 [PATCH 0/3] make the hugetlb migration strategy consistent Baolin Wang
2024-02-27 13:52 ` [PATCH 1/3] mm: record the migration reason for struct migration_target_control Baolin Wang
2024-02-27 15:10   ` Oscar Salvador
2024-02-28  7:40     ` Baolin Wang
2024-02-27 13:52 ` [PATCH 2/3] mm: hugetlb: make the hugetlb migration strategy consistent Baolin Wang
2024-02-27 15:17   ` Oscar Salvador [this message]
2024-02-28  7:40     ` Baolin Wang
2024-02-28  8:41       ` Oscar Salvador
2024-03-06  8:35         ` Baolin Wang
2024-03-06  8:46           ` Oscar Salvador
2024-03-06  8:58             ` Baolin Wang
2024-02-27 13:52 ` [PATCH 3/3] docs: hugetlbpage.rst: add hugetlb migration description Baolin Wang

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=Zd38_AYtr9QKp-F6@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=naoya.horiguchi@nec.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.