All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Michal Hocko <mhocko@suse.com>,
	Oscar Salvador <osalvador@suse.com>
Cc: Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-ia64@vger.kernel.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux-sh <linux-sh@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	"David S. Miller" <davem@davemloft.net>,
	Mark Brown <broonie@kernel.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Nicholas Piggin <npiggin@gmail.com>,
	Vasily Gorbik <gor@linux.ibm.com>, Rob Herring <robh@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	"mike.travis@hpe.com" <mike.travis@hpe.com>,
	Andrew Banman <andrew.banman@hpe.com>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Arun KS <arunks@codeaurora.org>, Qian Cai <cai@lca.pw>,
	Mathieu Malaterre <malat@debian.org>, Baoquan He <bhe@redhat.com>,
	Logan Gunthorpe <logang@deltatee.com>
Subject: Re: [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG
Date: Mon, 13 May 2019 10:20:43 +0200	[thread overview]
Message-ID: <fd061541-4433-d7a2-df73-66f39b61d0c9@redhat.com> (raw)
In-Reply-To: <c027a782-1cef-a076-92a3-3ce36140f3f2@redhat.com>

On 13.05.19 09:48, David Hildenbrand wrote:
> On 07.05.19 23:02, Dan Williams wrote:
>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Let's prepare for better error handling while adding memory by allowing
>>> to use arch_remove_memory() and __remove_pages() even if
>>> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE effectively
>>> covers
>>> - Offlining of system ram (memory block devices) - offline_pages()
>>> - Unplug of system ram - remove_memory()
>>> - Unplug/remap of device memory - devm_memremap()
>>>
>>> This allows e.g. for handling like
>>>
>>> arch_add_memory()
>>> rc = do_something();
>>> if (rc) {
>>>         arch_remove_memory();
>>> }
>>>
>>> Whereby do_something() will for example be memory block device creation
>>> after it has been factored out.
>>
>> What's left after this? Can we just get rid of CONFIG_MEMORY_HOTREMOVE
>> option completely when CONFIG_MEMORY_HOTPLUG is enabled? It's not
>> clear to me why there was ever the option to compile out the remove
>> code when the add code is included.
>>
> 
> If there are no other comments, I will go ahead and rip out
> CONFIG_MEMORY_HOTREMOVE completely, gluing the functionality to
> CONFIG_MEMORY_HOTPLUG.
> 

Hmmmm, however this will require CONFIG_MEMORY_HOTPLUG to require

- MEMORY_ISOLATION
- HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)

And depends on
- MIGRATION

Which would limit the configurations where memory hotplug would be
available. I guess going with this patch here is ok as a first step.

I just realized, that we'll need arch_remove_memory() for arm64 to make
this patch here work.

-- 

Thanks,

David / dhildenb

WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Michal Hocko <mhocko@suse.com>,
	Oscar Salvador <osalvador@suse.com>
Cc: Rich Felker <dalias@libc.org>,
	linux-ia64@vger.kernel.org, Linux-sh <linux-sh@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Linux MM <linux-mm@kvack.org>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Qian Cai <cai@lca.pw>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Vasily Gorbik <gor@linux.ibm.com>, Rob Herring <robh@kernel.org>,
	"mike.travis@hpe.com" <mike.travis@hpe.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Mark Brown <broonie@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tony Luck <tony.luck@intel.com>, Baoquan He <bhe@redhat.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Mathieu Malaterre <malat@debian.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Banman <andrew.banman@hpe.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Logan Gunthorpe <logang@deltatee.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Arun KS <arunks@codeaurora.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG
Date: Mon, 13 May 2019 10:20:43 +0200	[thread overview]
Message-ID: <fd061541-4433-d7a2-df73-66f39b61d0c9@redhat.com> (raw)
In-Reply-To: <c027a782-1cef-a076-92a3-3ce36140f3f2@redhat.com>

On 13.05.19 09:48, David Hildenbrand wrote:
> On 07.05.19 23:02, Dan Williams wrote:
>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Let's prepare for better error handling while adding memory by allowing
>>> to use arch_remove_memory() and __remove_pages() even if
>>> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE effectively
>>> covers
>>> - Offlining of system ram (memory block devices) - offline_pages()
>>> - Unplug of system ram - remove_memory()
>>> - Unplug/remap of device memory - devm_memremap()
>>>
>>> This allows e.g. for handling like
>>>
>>> arch_add_memory()
>>> rc = do_something();
>>> if (rc) {
>>>         arch_remove_memory();
>>> }
>>>
>>> Whereby do_something() will for example be memory block device creation
>>> after it has been factored out.
>>
>> What's left after this? Can we just get rid of CONFIG_MEMORY_HOTREMOVE
>> option completely when CONFIG_MEMORY_HOTPLUG is enabled? It's not
>> clear to me why there was ever the option to compile out the remove
>> code when the add code is included.
>>
> 
> If there are no other comments, I will go ahead and rip out
> CONFIG_MEMORY_HOTREMOVE completely, gluing the functionality to
> CONFIG_MEMORY_HOTPLUG.
> 

Hmmmm, however this will require CONFIG_MEMORY_HOTPLUG to require

- MEMORY_ISOLATION
- HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)

And depends on
- MIGRATION

Which would limit the configurations where memory hotplug would be
available. I guess going with this patch here is ok as a first step.

I just realized, that we'll need arch_remove_memory() for arm64 to make
this patch here work.

-- 

Thanks,

David / dhildenb

  reply	other threads:[~2019-05-13  8:20 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07 18:37 [PATCH v2 0/8] mm/memory_hotplug: Factor out memory block device handling David Hildenbrand
2019-05-07 18:37 ` David Hildenbrand
2019-05-07 18:37 ` [PATCH v2 1/8] mm/memory_hotplug: Simplify and fix check_hotplug_memory_range() David Hildenbrand
2019-05-07 18:37   ` David Hildenbrand
2019-05-07 18:37   ` David Hildenbrand
2019-05-07 20:38   ` Dan Williams
2019-05-07 20:38     ` Dan Williams
2019-05-07 20:38     ` Dan Williams
2019-05-07 20:38     ` Dan Williams
2019-05-09 12:23   ` Wei Yang
2019-05-09 12:23     ` Wei Yang
2019-05-09 12:23     ` Wei Yang
2019-05-07 18:37 ` [PATCH v2 2/8] s390x/mm: Implement arch_remove_memory() David Hildenbrand
2019-05-07 18:37   ` David Hildenbrand
2019-05-07 18:37   ` David Hildenbrand
2019-05-07 20:46   ` Dan Williams
2019-05-07 20:46     ` Dan Williams
2019-05-07 20:46     ` Dan Williams
2019-05-07 20:46     ` Dan Williams
2019-05-07 20:47     ` David Hildenbrand
2019-05-07 20:47       ` David Hildenbrand
2019-05-07 20:47       ` David Hildenbrand
2019-05-07 20:57       ` Dan Williams
2019-05-07 20:57         ` Dan Williams
2019-05-07 20:57         ` Dan Williams
2019-05-07 20:57         ` Dan Williams
2019-05-07 21:13         ` David Hildenbrand
2019-05-07 21:13           ` David Hildenbrand
2019-05-07 21:13           ` David Hildenbrand
2019-05-07 18:37 ` [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG David Hildenbrand
2019-05-07 18:37   ` David Hildenbrand
2019-05-07 21:02   ` Dan Williams
2019-05-07 21:02     ` Dan Williams
2019-05-07 21:02     ` Dan Williams
2019-05-07 21:06     ` David Hildenbrand
2019-05-07 21:06       ` David Hildenbrand
2019-05-13  7:48     ` David Hildenbrand
2019-05-13  7:48       ` David Hildenbrand
2019-05-13  8:20       ` David Hildenbrand [this message]
2019-05-13  8:20         ` David Hildenbrand
2019-05-07 18:38 ` [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory() David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 21:17   ` Dan Williams
2019-05-07 21:17     ` Dan Williams
2019-05-07 21:17     ` Dan Williams
2019-05-07 21:17     ` Dan Williams
2019-05-07 21:27     ` David Hildenbrand
2019-05-07 21:27       ` David Hildenbrand
2019-05-07 21:27       ` David Hildenbrand
2019-05-08  8:35   ` David Hildenbrand
2019-05-08  8:35     ` David Hildenbrand
2019-05-08  8:35     ` David Hildenbrand
2019-05-09 12:43   ` Wei Yang
2019-05-09 12:43     ` Wei Yang
2019-05-09 12:43     ` Wei Yang
2019-05-09 12:50     ` David Hildenbrand
2019-05-09 12:50       ` David Hildenbrand
2019-05-09 12:50       ` David Hildenbrand
2019-05-09 13:55   ` Wei Yang
2019-05-09 13:55     ` Wei Yang
2019-05-09 13:55     ` Wei Yang
2019-05-09 14:05     ` David Hildenbrand
2019-05-09 14:05       ` David Hildenbrand
2019-05-09 14:05       ` David Hildenbrand
2019-05-09 14:31   ` Wei Yang
2019-05-09 14:31     ` Wei Yang
2019-05-09 14:31     ` Wei Yang
2019-05-09 14:58     ` David Hildenbrand
2019-05-09 14:58       ` David Hildenbrand
2019-05-09 14:58       ` David Hildenbrand
2019-05-09 21:50       ` Wei Yang
2019-05-09 21:50         ` Wei Yang
2019-05-09 21:50         ` Wei Yang
2019-05-09 22:18         ` David Hildenbrand
2019-05-09 22:18           ` David Hildenbrand
2019-05-09 22:18           ` David Hildenbrand
2019-05-07 18:38 ` [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 21:19   ` Dan Williams
2019-05-07 21:19     ` Dan Williams
2019-05-07 21:19     ` Dan Williams
2019-05-07 21:19     ` Dan Williams
2019-05-07 21:24     ` David Hildenbrand
2019-05-07 21:24       ` David Hildenbrand
2019-05-07 21:24       ` David Hildenbrand
2019-05-07 21:25       ` Dan Williams
2019-05-07 21:25         ` Dan Williams
2019-05-07 21:25         ` Dan Williams
2019-05-07 21:25         ` Dan Williams
2019-05-08  7:39         ` David Hildenbrand
2019-05-08  7:39           ` David Hildenbrand
2019-05-08  7:39           ` David Hildenbrand
2019-05-08 23:08           ` osalvador
2019-05-08 23:08             ` osalvador
2019-05-08 23:08             ` osalvador
2019-05-08 23:08             ` osalvador
2019-05-09  7:05             ` David Hildenbrand
2019-05-09  7:05               ` David Hildenbrand
2019-05-09  7:05               ` David Hildenbrand
2019-05-07 18:38 ` [PATCH v2 6/8] mm/memory_hotplug: Remove memory block devices before arch_remove_memory() David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 21:27   ` Dan Williams
2019-05-07 21:27     ` Dan Williams
2019-05-07 21:27     ` Dan Williams
2019-05-07 21:27     ` Dan Williams
2019-05-07 18:38 ` [PATCH v2 7/8] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-08  0:15   ` Dan Williams
2019-05-08  0:15     ` Dan Williams
2019-05-08  0:15     ` Dan Williams
2019-05-08  0:15     ` Dan Williams
2019-05-08  7:21     ` David Hildenbrand
2019-05-08  7:21       ` David Hildenbrand
2019-05-08  7:21       ` David Hildenbrand
2019-05-08 13:50       ` Dan Williams
2019-05-08 13:50         ` Dan Williams
2019-05-08 13:50         ` Dan Williams
2019-05-08 13:50         ` Dan Williams
2019-05-07 18:38 ` [PATCH v2 8/8] mm/memory_hotplug: Remove "zone" parameter from sparse_remove_one_section David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-07 18:38   ` David Hildenbrand
2019-05-08  0:30   ` Dan Williams
2019-05-08  0:30     ` Dan Williams
2019-05-08  0:30     ` Dan Williams
2019-05-08  0:30     ` Dan Williams
2019-05-07 19:04 ` [PATCH v2 0/8] mm/memory_hotplug: Factor out memory block device handling Dan Williams
2019-05-07 19:04   ` Dan Williams
2019-05-07 19:04   ` Dan Williams
2019-05-07 19:21   ` David Hildenbrand
2019-05-07 19:21     ` David Hildenbrand
2019-05-07 19:37     ` David Hildenbrand
2019-05-07 19:37       ` David Hildenbrand
2019-05-07 20:36       ` Dan Williams
2019-05-07 20:36         ` Dan Williams
2019-05-07 20:36         ` Dan Williams

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=fd061541-4433-d7a2-df73-66f39b61d0c9@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=andrew.banman@hpe.com \
    --cc=arunks@codeaurora.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=cai@lca.pw \
    --cc=chris@chris-wilson.co.uk \
    --cc=christophe.leroy@c-s.fr \
    --cc=dalias@libc.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=fenghua.yu@intel.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=logang@deltatee.com \
    --cc=luto@kernel.org \
    --cc=malat@debian.org \
    --cc=mhocko@suse.com \
    --cc=mike.travis@hpe.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=osalvador@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=robh@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=ysato@users.sourceforge.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.