All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	20230519105321.333-1-ssawgyw@gmail.com,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	tsahu@linux.ibm.com, ssawgyw@gmail.com
Subject: Re: [PATCH] memblock: update numa node of memblk reserved type
Date: Wed, 24 May 2023 18:33:44 +0300	[thread overview]
Message-ID: <20230524153344.GM4967@kernel.org> (raw)
In-Reply-To: <4eb83d16-58ed-9f09-4308-f0f786580257@huawei.com>

On Wed, May 24, 2023 at 02:47:26PM +0800, Kefeng Wang wrote:
> 
> On 2023/5/24 12:59, Anshuman Khandual wrote:
> > 
> > On 5/23/23 17:27, Kefeng Wang wrote:
> > > The numa node of memblk reserved type is wrong, it could update
> > > according to the numa node information from memblk memory type,
> > > let's fix it.
> > 
> > Indeed it's wrong at present and can be verified from sysfs file
> > (/sys/kernel/debug/memblock/reserved) accessed in user space.
> 
> Yes, both memblock_dump() and sysfs show wrong value.
> > 
> > > 
> > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> > > ---
> > >   mm/memblock.c | 25 +++++++++++++++++++++++++
> > >   1 file changed, 25 insertions(+)
> > > 
> > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > index a50447d970ef..45a0781cda31 100644
> > > --- a/mm/memblock.c
> > > +++ b/mm/memblock.c
> > > @@ -1922,6 +1922,28 @@ phys_addr_t __init_memblock memblock_get_current_limit(void)
> > >   	return memblock.current_limit;
> > >   }
> > > +static void __init_memblock memblock_reserved_update_node(void)
> > > +{
> > > +	struct memblock_region *rgn;
> > > +	phys_addr_t base, end, size;
> > > +	int ret;
> > > +
> > > +	if (!IS_ENABLED(CONFIG_NUMA))
> > > +		return;
> > > +
> > > +	for_each_mem_region(rgn) {
> > > +		base = rgn->base;
> > > +		size = rgn->size;
> > > +		end = base + size - 1;
> > > +
> > > +		ret = memblock_set_node(base, size, &memblock.reserved,
> > > +					memblock_get_region_node(rgn));
> > > +		if (ret)
> > > +			pr_err("memblock: Failed to update reserved [%pa-%pa] node",
> > > +			       &base, &end);
> > > +	}
> > > +}
> > > +
> > >   static void __init_memblock memblock_dump(struct memblock_type *type)
> > >   {
> > >   	phys_addr_t base, end, size;
> > > @@ -1955,6 +1977,7 @@ static void __init_memblock __memblock_dump_all(void)
> > >   		&memblock.memory.total_size,
> > >   		&memblock.reserved.total_size);
> > > +	memblock_reserved_update_node();
> > 
> > __memblock_dump_all() gets called only when memblock_debug is enabled.
> > This helper should be called directly inside memblock_dump_all() right
> > at the beginning, regardless of memblock_debug.
> 
> This is my first though, but I found there are still many memblock_alloc and
> memblock_reserve after memblock_dump_all(), so I update it twice,
> 
> 1) __memblock_dump_all()
> 2) memblock_debug_show()
> 
> and without the above two interface, no one care about the reserved node
> info, so I put memblock_reserved_update_node into __memblock_dump_all().
 
We don't care about the reserved node info and __memblock_dump_all()
actually does not print node info for reserved regions unless somebody
explicitly sets the node id on a reserved memory.

So instead of updating reserved memory node info I'd rather avoid printing
it in debugfs.
 
> > >   #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
> > > @@ -2196,6 +2219,8 @@ static int memblock_debug_show(struct seq_file *m, void *private)
> > >   	unsigned int count = ARRAY_SIZE(flagname);
> > >   	phys_addr_t end;
> > > +	memblock_reserved_update_node();
> > > +
> > 
> 
> > This is redundant, should be dropped. Reserved memblock ranges need not
> > be scanned, each time the sysfs file is accessed from user space.
> 
> Yes, it's better to move it into memblock_init_debugfs(),
> which only called once.
> 
> 
> 

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2023-05-24 15:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 11:57 [PATCH] memblock: update numa node of memblk reserved type Kefeng Wang
2023-05-24  4:59 ` Anshuman Khandual
2023-05-24  6:47   ` Kefeng Wang
2023-05-24 15:33     ` Mike Rapoport [this message]
2023-05-25  1:28       ` Kefeng 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=20230524153344.GM4967@kernel.org \
    --to=rppt@kernel.org \
    --cc=20230519105321.333-1-ssawgyw@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ssawgyw@gmail.com \
    --cc=tsahu@linux.ibm.com \
    --cc=wangkefeng.wang@huawei.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.