From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Harry Yoo <harry.yoo@oracle.com>, Rakie Kim <rakie.kim@sk.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] mm,memory_hotplug: Implement numa node notifier
Date: Thu, 5 Jun 2025 07:18:43 +0200 [thread overview]
Message-ID: <aEEos-bG7cq0C8gI@localhost.localdomain> (raw)
In-Reply-To: <9a845c21-5cfb-4535-97bd-0b02f5852457@redhat.com>
On Wed, Jun 04, 2025 at 02:47:28PM +0200, David Hildenbrand wrote:
> Just to clarify, these were the 3 notifiers each that belong together. I was
> not sure about NODE_CANCEL_ADDING_FIRST_MEMORY vs.
> NODE_NOT_ADDED_FIRST_MEMORY.
I started working on the new respin and the moment came to make a
decision about this.
I think I'd go with NODE_CANCEL_ADDING_FIRST_MEMORY, for two reasons.
One is that memory notifier also uses that therminology, so I'd use that
one for the node notifier to keep it consistent.
Someone could argue whether we are perpetuating a bad decision naming
though :-).
The other reason is that to me, it sounds more natural as the way I see
it, we are canceling an ongoing operation (memory-hotplug).
Now, I can also see the point in the NODE_NOT_ADDED because the memory
could "not be added in the end", but at the end of the way only one can be picked :-D.
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2025-06-05 5:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 11:08 [PATCH v4 0/3] " Oscar Salvador
2025-06-03 11:08 ` [PATCH v4 1/3] mm,slub: Do not special case N_NORMAL nodes for slab_nodes Oscar Salvador
2025-06-04 9:28 ` Harry Yoo
2025-06-04 11:33 ` David Hildenbrand
2025-06-04 12:16 ` Yunsheng Lin
2025-06-03 11:08 ` [PATCH v4 2/3] mm,memory_hotplug: Implement numa node notifier Oscar Salvador
2025-06-04 12:03 ` David Hildenbrand
2025-06-04 12:38 ` Oscar Salvador
2025-06-04 12:47 ` David Hildenbrand
2025-06-05 5:18 ` Oscar Salvador [this message]
2025-06-05 8:12 ` David Hildenbrand
2025-06-03 11:08 ` [PATCH v4 3/3] mm,memory_hotplug: Rename status_change_nid parameter in memory_notify Oscar Salvador
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=aEEos-bG7cq0C8gI@localhost.localdomain \
--to=osalvador@suse.de \
--cc=42.hyeyoo@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rakie.kim@sk.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox