linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Oscar Salvador <osalvador@suse.de>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Wei Yang <richard.weiyang@gmail.com>, Qian Cai <cai@lca.pw>,
	Arun KS <arunks@codeaurora.org>,
	Mathieu Malaterre <malat@debian.org>
Subject: Re: [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory()
Date: Wed, 17 Apr 2019 15:24:47 +0200	[thread overview]
Message-ID: <ae4cc790-8d9b-39ad-d29c-d8bd290da165@redhat.com> (raw)
In-Reply-To: <20190417131258.GI5878@dhcp22.suse.cz>

On 17.04.19 15:12, Michal Hocko wrote:
> On Tue 09-04-19 12:01:45, David Hildenbrand wrote:
>> __add_pages() doesn't add the memory resource, so __remove_pages()
>> shouldn't remove it. Let's factor it out. Especially as it is a special
>> case for memory used as system memory, added via add_memory() and
>> friends.
>>
>> We now remove the resource after removing the sections instead of doing
>> it the other way around. I don't think this change is problematic.
>>
>> add_memory()
>> 	register memory resource
>> 	arch_add_memory()
>>
>> remove_memory
>> 	arch_remove_memory()
>> 	release memory resource
>>
>> While at it, explain why we ignore errors and that it only happeny if
>> we remove memory in a different granularity as we added it.
> 
> OK, I agree that the symmetry is good in general and it certainly makes
> sense here as well. But does it make sense to pick up this particular
> part without larger considerations of add vs. remove apis? I have a
> strong feeling this wouldn't be the only thing to care about. In other
> words does this help future changes or it is more likely to cause more
> code conflicts with other features being developed right now?

I am planning to

1. factor out memory block device handling, so features like sub-section
add/remove are easier to add internally. Move it to the user that wants
it. Clean up all the mess we have right now due to supporting memory
block devices that span several sections.

2. Make sure that any arch_add_pages() and friends clean up properly if
they fail instead of indicating failure but leaving some partially added
memory lying around.

3. Clean up node handling regarding to memory hotplug/unplug. Especially
don't allow to offline/remove memory spanning several nodes etc.

IOW, in order to properly clean up memory block device handling and
prepare for more changes people are interested in (e.g. sub-section add
of device memory), this is the right thing to do. The other parts are
bigger changes.

-- 

Thanks,

David / dhildenb


  reply	other threads:[~2019-04-17 13:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 10:01 [PATCH v1 0/4] mm/memory_hotplug: Better error handling when removing memory David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory() David Hildenbrand
2019-04-09 22:41   ` Andrew Morton
2019-04-10  8:07     ` David Hildenbrand
2019-04-17  3:37       ` Andrew Morton
2019-04-17  7:44         ` David Hildenbrand
2019-04-17 11:52   ` Oscar Salvador
2019-04-17 12:02   ` [PATCH] mm/memory_hotplug: Fixup "Release memory resource after arch_remove_memory()" David Hildenbrand
2019-04-17 13:12   ` [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory() Michal Hocko
2019-04-17 13:24     ` David Hildenbrand [this message]
2019-04-17 13:31       ` Michal Hocko
2019-04-17 13:48         ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 2/4] mm/memory_hotplug: Make unregister_memory_section() never fail David Hildenbrand
2019-04-17 12:45   ` Oscar Salvador
2019-04-17 13:10     ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 3/4] mm/memory_hotplug: Make __remove_section() " David Hildenbrand
2019-04-17 13:56   ` Oscar Salvador
2019-04-24  6:54     ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 4/4] mm/memory_hotplug: Make __remove_pages() and arch_remove_memory() " David Hildenbrand

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=ae4cc790-8d9b-39ad-d29c-d8bd290da165@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arunks@codeaurora.org \
    --cc=cai@lca.pw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=malat@debian.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=richard.weiyang@gmail.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 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).