All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yajun Deng" <yajun.deng@linux.dev>
To: "Mike Rapoport" <rppt@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memblock: Introduce memblock_reserve_node()
Date: Wed, 28 Jun 2023 01:49:16 +0000	[thread overview]
Message-ID: <45683de8eea1912297542aad909ece6d@linux.dev> (raw)
In-Reply-To: <20230627143318.GN52412@kernel.org>

June 27, 2023 10:33 PM, "Mike Rapoport" <rppt@kernel.org> wrote:

> On Tue, Jun 27, 2023 at 12:13:16AM +0000, Yajun Deng wrote:
> 
>> June 26, 2023 2:21 PM, "Mike Rapoport" <rppt@kernel.org> wrote:
>> 
>> On Sun, Jun 25, 2023 at 07:39:10AM +0000, Yajun Deng wrote:
>> 
>> June 25, 2023 1:08 PM, "Mike Rapoport" <rppt@kernel.org> wrote:
>> 
>> On Sat, Jun 24, 2023 at 10:46:22AM +0800, Yajun Deng wrote:
>> 
>> It only returns address now in memblock_find_in_range_node(), we can add a
>> parameter pointing to integer for node id of the range, which can be used
>> to pass the node id to the new reserve region.
>> 
>> Introduce memblock_reserve_node() so that the node id can be passed to
>> the reserve region in memblock_alloc_range_nid().
>> 
>> Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
>> 
>> What problem does this patch solve?
>> 
>> If we set nid and flags in memblock_alloc_range_nid(), we may not need
>> memblock_set_node() in memmap_init_reserved_pages().
>> 
>> When memblock_reserve() is called before NUMA setup, the node ids are still
>> unset in memblock.memory, so very early reservations will be missed and we
>> still have to update node ids in memblock.reserved later.
>> 
>> Even so, we still need to pass the 'flags' to the new reserve region.
>> choose_memblock_flags() may return MEMBLOCK_MIRROR in memblock_alloc_range_nid(),
>> memblock_reserve() couldn't pass this flag in this case.
> 
> flags are only relevant to memblock.memory, we don't care about the flags
> in memblock.reserved.
> 

get it.

>> I tested this patch and delete memblock_set_node() in memmap_init_reserved_pages().
>> It works fine. I did not delete memblock_set_node() in this patch just in case.
>> 
>> --
>> Sincerely yours,
>> Mike.
> 
> --
> Sincerely yours,
> Mike.


      reply	other threads:[~2023-06-28  1:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-24  2:46 [PATCH] memblock: Introduce memblock_reserve_node() Yajun Deng
2023-06-25  5:08 ` Mike Rapoport
2023-06-25  7:39   ` Yajun Deng
2023-06-26  6:21     ` Mike Rapoport
2023-06-27  0:13       ` Yajun Deng
2023-06-27 14:33         ` Mike Rapoport
2023-06-28  1:49           ` Yajun Deng [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=45683de8eea1912297542aad909ece6d@linux.dev \
    --to=yajun.deng@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    /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.