linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
To: Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	David Hildenbrand <david@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org (open list:HUGETLB SUBSYSTEM),
	linux-kernel@vger.kernel.org (open list)
Cc: skhan@linuxfoundation.org, david.hunter.linux@gmail.com,
	Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
Subject: [RFC] hugetlb: add memory-hotplug notifier to only allocate for online nodes
Date: Thu,  6 Nov 2025 08:56:41 +0000	[thread overview]
Message-ID: <20251106085645.13607-1-swarajgaikwad1925@gmail.com> (raw)

This patch is a RFC on a proposed change to the hugetlb cgroup subsystem’s
css allocation function.

The existing hugetlb_cgroup_css_alloc() uses for_each_node() to allocate
nodeinfo for all nodes, including those which are not online yet
(or never will be). This can waste considerable memory on large-node systems.
The documentation already lists this as a TODO.

Proposed Change:
    Introduce a memory hotplug notifier that listens for MEM_ONLINE
    events. When a node becomes online, we call the same allocation function
    but insted of for_each_node(),using for_each_online_node(). This means
    memory is only allocated for nodes which are online, thus reducing waste.

Feedback Requested:
    - Where in the codebase (which file or section) is it most appropriate to
      implement and register the memory hotplug notifier for this subsystem?
    - Are there best practices or patterns for handling the notifier lifecycle,
      especially for unregistering during cgroup or subsystem teardown?
    - What are the standard methods or tools to test memory hotplug scenarios
      for cgroups? Are there ways to reliably trigger node online/offline events
      in a development environment?
    - Are there existing test cases or utilities in the kernel tree that would help
      to verify correct behavior of this change?
    - Any suggestions for implementation improvements or cleaner API usage?

Thanks,
Swaraj Gaikwad <swarajgaikwad1925@gmail.com>

Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>


             reply	other threads:[~2025-11-06  3:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06  8:56 Swaraj Gaikwad [this message]
2025-11-06 10:01 ` David Hildenbrand (Red Hat)

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=20251106085645.13607-1-swarajgaikwad1925@gmail.com \
    --to=swarajgaikwad1925@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david.hunter.linux@gmail.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox