linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Charan Teja Kalla <charante@codeaurora.org>
To: David Hildenbrand <david@redhat.com>,
	akpm@linux-foundation.org, rientjes@google.com, vbabka@suse.cz,
	mhocko@suse.com, mgorman@techsingularity.net, linux-mm@kvack.org
Cc: vinmenon@codeaurora.org, sudaraja@codeaurora.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/1] mm: balancing the node zones occupancy
Date: Tue, 23 Feb 2021 18:00:01 +0530	[thread overview]
Message-ID: <d1590275-b70d-5e09-5047-cc0fa268b583@codeaurora.org> (raw)
In-Reply-To: <82e0e9c2-8187-8e2f-0d5e-304dafcda017@redhat.com>


Thanks David for the review comments!!

On 2/18/2021 11:46 PM, David Hildenbrand 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.
> 
> Why is this specific to memory hot(un)plug? I think the problem is more
> generic:
> 
> Assume
> 
> 1. Application 1 allocates a lot of memory and gets ZONE_MOVABLE.
> 2. Application 2 allocates a lot of memory and gets ZONE_NORMAL.
> 3. Application 1 quits.
> 
> Same problem, no?

Thanks for simplifying this problem. Yeah, this looks more generic
problem. But for these type of problems, user/system administrator has
clear view about the state of the system and thus may need to take some
decisions to maintain the the node zones balancing e.g. like this change
where migrate the eligible pages to other zones.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project


  reply	other threads:[~2021-02-23 12:30 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 [this message]
2021-02-19 11:26 ` Vlastimil Babka
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=d1590275-b70d-5e09-5047-cc0fa268b583@codeaurora.org \
    --to=charante@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --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=vbabka@suse.cz \
    --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).