From: Vlastimil Babka <vbabka@suse.cz>
To: Charan Teja Reddy <charante@codeaurora.org>,
akpm@linux-foundation.org, rientjes@google.com, mhocko@suse.com,
david@redhat.com, mgorman@techsingularity.net,
linux-mm@kvack.org
Cc: vinmenon@codeaurora.org, sudaraja@codeaurora.org,
linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH RFC 0/1] mm: balancing the node zones occupancy
Date: Fri, 19 Feb 2021 12:26:41 +0100 [thread overview]
Message-ID: <1c445421-ddeb-8768-03d0-81537b0d1875@suse.cz> (raw)
In-Reply-To: <cover.1613661472.git.charante@codeaurora.org>
On 2/18/21 6:24 PM, Charan Teja Reddy wrote:
> I would like to start discussion about balancing the occupancy of
> memory zones in a node in the system whose imabalance may be caused by
> migration of pages to other zones during hotremove and then hotadding
> same memory. In this case there is a lot of free memory in newly hotadd
> memory which can be filled up by the previous migrated pages(as part of
> offline/hotremove) thus may free up some pressure in other zones of the
> node.
Can you share the use case for doing this? If it's to replace a failed RAM, then
it's probably extremely rare, right.
> We have the proof-of-concept code tried on the Snapdragon systems with
> the system configuration, single memory node of just 2 zones, 6GB normal
> zone and 2GB movable zone. And this Movable zone is such that hot-added
> once and there after offline/online based on the need.
Hm, snapdragon... so is this some kind of power saving thing?
Anyway, shouln't auto NUMA balancing help here, and especially "Migrate Pages in
lieu of discard" (CC'd Dave) as a generic mechanism, so we wouldn't need to have
hotplug-specific actions?
next prev parent reply other threads:[~2021-02-19 11:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 17:24 [PATCH RFC 0/1] mm: balancing the node zones occupancy Charan Teja Reddy
2021-02-18 17:24 ` [PATCH 1/1] mm: proof-of-concept for balancing " Charan Teja Reddy
2021-02-18 18:16 ` [PATCH RFC 0/1] mm: balancing the " David Hildenbrand
2021-02-23 12:30 ` Charan Teja Kalla
2021-02-19 11:26 ` Vlastimil Babka [this message]
2021-02-23 13:45 ` Charan Teja Kalla
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=1c445421-ddeb-8768-03d0-81537b0d1875@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=charante@codeaurora.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=sudaraja@codeaurora.org \
--cc=vinmenon@codeaurora.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;
as well as URLs for NNTP newsgroup(s).