Re: [PATCH RFC 7/7] mm: better document PG_reserved

On 05.12.18 15:35, Matthew Wilcox wrote: > On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote: >> I don't see a reason why we have to document "Some of them might not even >> exist". If there is a user, we should document it. E.g. for balloon >>

Re: [PATCH RFCv2 1/4] mm/memory_hotplug: Introduce memory block types

On 01.12.18 02:25, Wei Yang wrote: > On Fri, Nov 30, 2018 at 06:59:19PM +0100, David Hildenbrand wrote: >> Memory onlining should always be handled by user space, because only user >> space knows which use cases it wants to satisfy. E.g. memory might be >> onlined to

Re: [PATCH RFCv2 2/4] mm/memory_hotplug: Replace "bool want_memblock" by "int type"

On 01.12.18 02:50, Wei Yang wrote: > On Fri, Nov 30, 2018 at 06:59:20PM +0100, David Hildenbrand wrote: >> Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device >> memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No >>

Re: [PATCH RFC 7/7] mm: better document PG_reserved

On 05.12.18 19:13, David Hildenbrand wrote: > On 05.12.18 18:32, Matthew Wilcox wrote: >> On Wed, Dec 05, 2018 at 04:05:12PM +0100, David Hildenbrand wrote: >>> On 05.12.18 15:35, Matthew Wilcox wrote: >>>> On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hilden

[PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

online_type) we are using in that context. - The "removable" property should never have been named like that. It should have been "offlinable". Can we still rename that? E.g. boot memory is sometimes marked as removable ... David Hildenbrand (4): mm/memory_hotplug

Re: [PATCH RFC 7/7] mm: better document PG_reserved

On 05.12.18 18:32, Matthew Wilcox wrote: > On Wed, Dec 05, 2018 at 04:05:12PM +0100, David Hildenbrand wrote: >> On 05.12.18 15:35, Matthew Wilcox wrote: >>> On Wed, Dec 05, 2018 at 01:28:51PM +0100, David Hildenbrand wrote: >>>> I don't see a reason why we have t

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 28.09.18 17:03, David Hildenbrand wrote: > How to/when to online hotplugged memory is hard to manage for > distributions because different memory types are to be treated differently. > Right now, we need complicated udev rules that e.g. check if we are > running on s390x, on a phy

Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" Hopefully you found most users :) Did you check if some are encoded into function calls? f(-1, ...) Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 27.11.18 17:32, Michal Suchánek wrote: > On Mon, 26 Nov 2018 16:59:14 +0100 > David Hildenbrand wrote: > >> On 26.11.18 15:20, Michal Suchánek wrote: >>> On Mon, 26 Nov 2018 14:33:29 +0100 >>> David Hildenbrand wrote: >>> >&

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 23.11.18 19:06, Michal Suchánek wrote: > On Fri, 23 Nov 2018 12:13:58 +0100 > David Hildenbrand wrote: > >> On 28.09.18 17:03, David Hildenbrand wrote: >>> How to/when to online hotplugged memory is hard to manage for >>> distributions because differe

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 26.11.18 13:30, David Hildenbrand wrote: > On 23.11.18 19:06, Michal Suchánek wrote: >> On Fri, 23 Nov 2018 12:13:58 +0100 >> David Hildenbrand wrote: >> >>> On 28.09.18 17:03, David Hildenbrand wrote: >>>> How to/when to online hotplugged memor

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 26.11.18 15:20, Michal Suchánek wrote: > On Mon, 26 Nov 2018 14:33:29 +0100 > David Hildenbrand wrote: > >> On 26.11.18 13:30, David Hildenbrand wrote: >>> On 23.11.18 19:06, Michal Suchánek wrote: > >>>> >>>> If we are going to fake the

Re: [PATCH v2 2/2] powerpc: use probe_user_read()

On 08.01.19 08:37, Christophe Leroy wrote: > Instead of opencoding, use probe_user_read() to failessly > read a user location. > > Signed-off-by: Christophe Leroy > --- > v2: Using probe_user_read() instead of probe_user_address() > > arch/powerpc/kernel/process.c | 12 +--- >

[PATCH v2 8/9] ia64: perfmon: Don't mark buffer pages as PG_reserved

()/vfree() instead. Note that before calling vzalloc(), size has already been aligned to PAGE_SIZE, no need to align again. Cc: Tony Luck Cc: Fenghua Yu Cc: Oleg Nesterov Cc: Andrew Morton Cc: David Hildenbrand Cc: David Howells Cc: Mike Rapoport Cc: Michal Hocko Signed-off-by: David Hildenbrand

[PATCH v2 4/9] riscv/vdso: don't clear PG_reserved

Cc: Tobias Klauser Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Acked-by: Palmer Dabbelt Signed-off-by: David Hildenbrand --- arch/riscv/kernel/vdso.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c index 582cb153eb24

[PATCH v2 0/9] mm: PG_reserved cleanups and documentation

_reserved" - Add "ia64: perfmon: Don't mark buffer pages as PG_reserved" - Added ACKs David Hildenbrand (9): agp: efficeon: no need to set PG_reserved on GATT tables s390/vdso: don't clear PG_reserved powerpc/vdso: don't clear PG_reserved riscv/vdso: don't clear PG_reserve

[PATCH v2 2/9] s390/vdso: don't clear PG_reserved

Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Matthew Wilcox Cc: Mike Rapoport Cc: Michal Hocko Cc: Vasily Gorbik Cc: Kees Cook Cc: Souptick Joarder Cc: Andrew Morton Cc: Michal Hocko Signed-off-by: David Hildenbrand --- arch/s390/kernel/vdso.c | 2 -- 1 file changed, 2 deletions

[PATCH v2 5/9] m68k/mm: use __ClearPageReserved()

The PG_reserved flag is cleared from memory that is part of the kernel image (and therefore marked as PG_reserved). Avoid using PG_reserved directly. Cc: Geert Uytterhoeven Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/m68k/mm/memory.c | 2

[PATCH v2 6/9] arm64: kexec: no need to ClearPageReserved()

This will be done by free_reserved_page(). Cc: Catalin Marinas Cc: Will Deacon Cc: Bhupesh Sharma Cc: James Morse Cc: Marc Zyngier Cc: Dave Kleikamp Cc: Mark Rutland Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Acked-by: James Morse Signed-off-by: David Hildenbrand --- arch

[PATCH v2 3/9] powerpc/vdso: don't clear PG_reserved

: Paul Mackerras Cc: Michael Ellerman Cc: Christophe Leroy Cc: Kees Cook Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Acked-by: Michael Ellerman (powerpc) Signed-off-by: David Hildenbrand --- arch/powerpc/kernel/vdso.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc

[PATCH v2 9/9] mm: better document PG_reserved

tashin Cc: Michal Hocko Cc: Alexander Duyck Cc: Matthew Wilcox Cc: Anthony Yznaga Cc: Miles Chen Cc: yi.z.zh...@linux.intel.com Cc: Dan Williams Cc: Randy Dunlap Signed-off-by: David Hildenbrand --- include/linux/page-flags.h | 33 +++-- 1 file changed, 31

[PATCH v2 7/9] arm64: kdump: No need to mark crashkernel pages manually PG_reserved

they would have been handed over to the buddy as free pages and bad things would happen). Cc: Catalin Marinas Cc: Will Deacon Cc: James Morse Cc: Bhupesh Sharma Cc: David Hildenbrand Cc: Mark Rutland Cc: Dave Kleikamp Cc: Andrew Morton Cc: Mike Rapoport Cc: Michal Hocko Cc: Florian

[PATCH v2 1/9] agp: efficeon: no need to set PG_reserved on GATT tables

from that, these pages are not exposed or ioremap'ed. We can stop setting them reserved (propably copied from generic code). Cc: David Airlie Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- drivers/char/agp

Re: [PATCH v1 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

Am 19.09.18 um 03:22 schrieb Balbir Singh: > On Tue, Sep 18, 2018 at 01:48:16PM +0200, David Hildenbrand wrote: >> Reading through the code and studying how mem_hotplug_lock is to be used, >> I noticed that there are two places where we can end up calling >> device_on

Re: [PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

Am 03.09.18 um 02:36 schrieb Rashmica: > Hi David, > > > On 21/08/18 20:44, David Hildenbrand wrote: > >> There seem to be some problems as result of 30467e0b3be ("mm, hotplug: >> fix concurrent memory hot-add deadlock"), which tried to fix a possible >

[PATCH v1 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

device_online() should be called with device_hotplug_lock() held. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Reviewed-by: Pavel Tatashin Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv

[PATCH v1 6/6] memory-hotplug.txt: Add some details about locking internals

-by: David Hildenbrand --- Documentation/memory-hotplug.txt | 39 +++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 7f49ebf3ddb2..03aaad7d7373 100644 --- a/Documentation/memory

[PATCH v1 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

c: YASUAKI ISHIMATSU Cc: Mathieu Malaterre Reviewed-by: Pavel Tatashin Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 2 -- arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++--- drivers/acpi/acpi_memhotplug.c | 2 +- inc

[PATCH v1 5/6] powerpc/powernv: hold device_hotplug_lock in memtrace_offline_pages()

Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c index ef7181d4fe68..473e59842ec5 100644 --- a/arch

[PATCH v1 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

Added rb's RFC -> RFCv2: - Don't export device_hotplug_lock, provide proper remove_memory/add_memory wrappers. - Split up the patches a bit. - Try to improve powernv memtrace locking - Add some documentation for locking that matches my knowledge David Hildenbrand (6): mm/memory_hotplu

[PATCH v1 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

trovsky Cc: Juergen Gross Cc: Nathan Fontenot Cc: John Allen Cc: Andrew Morton Cc: Michal Hocko Cc: Dan Williams Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Oscar Salvador Cc: Mathieu Malaterre Cc: Pavel Tatashin Cc: YASUAKI ISHIMATSU Reviewed-by: Pavel Tatashin Signed-off-by: David Hildenbrand

[PATCH v1 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

n Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 13 + mm/memory_hotplug.c | 28 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 40c

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

On 20.12.18 14:08, Michal Hocko wrote: > On Thu 20-12-18 13:58:16, David Hildenbrand wrote: >> On 30.11.18 18:59, David Hildenbrand wrote: >>> This is the second approach, introducing more meaningful memory block >>> types and not changing online behavior in the kernel

Re: [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG

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 wrote: >>> >>> Let's prepare for better error handling while adding memory by allowing >>> to use arch_remov

Re: [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG

On 07.05.19 23:02, Dan Williams wrote: > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: >> >> Let's prepare for better error handling while adding memory by allowing >> to use arch_remove_memory() and __remove_pages() even if >> CONFIG_

[PATCH v3 09/11] mm/memory_hotplug: Remove memory block devices before arch_remove_memory()

() and arch_remove_memory(). Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hildenbrand Cc: "mike.tra...@hpe.com" Cc: Andrew Morton Cc: Andrew Banman Cc: Ingo Molnar Cc: Alex Deucher Cc: "David S. Miller" Cc: Mark Brown Cc: Chris Wilson Cc: Oscar Salv

[PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation

: Mike Rapoport Cc: Jun Yao Cc: Yu Zhao Cc: Robin Murphy Cc: Anshuman Khandual Signed-off-by: David Hildenbrand --- arch/arm64/mm/mmu.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index a1bfc4413982..e569a543c384 100644

[PATCH v3 05/11] drivers/base/memory: Pass a block_id to init_memory_block()

We'll rework hotplug_memory_register() shortly, so it no longer consumes pass a section. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/dr

[PATCH v3 06/11] mm/memory_hotplug: Allow arch_remove_pages() without CONFIG_MEMORY_HOTREMOVE

Cc: Rich Felker Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Michal Hocko Cc: Mike Rapoport Cc: David Hi

[PATCH v3 10/11] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail

ced off and never removed. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Alex Deucher Cc: "David S. Miller" Cc: Mark Brown Cc: Chris Wilson Cc: David Hildenbrand Cc: Oscar Salvador Cc: Andrew Morton Cc: Jonathan Cameron Signed-off-by: David Hildenbrand --- dr

[PATCH v3 11/11] mm/memory_hotplug: Remove "zone" parameter from sparse_remove_one_section

The parameter is unused, so let's drop it. Memory removal paths should never care about zones. This is the job of memory offlining and will require more refactorings. Reviewed-by: Dan Williams Signed-off-by: David Hildenbrand --- include/linux/memory_hotplug.h | 2 +- mm/memory_hotplug.c

[PATCH v3 01/11] mm/memory_hotplug: Simplify and fix check_hotplug_memory_range()

By converting start and size to page granularity, we actually ignore unaligned parts within a page instead of properly bailing out with an error. Cc: Andrew Morton Cc: Oscar Salvador Cc: Michal Hocko Cc: David Hildenbrand Cc: Pavel Tatashin Cc: Qian Cai Cc: Wei Yang Cc: Arun KS Cc

[PATCH v3 07/11] mm/memory_hotplug: Create memory block devices after arch_add_memory()

unregister_memory() - introduce find_memory_block_by_id() to search via block id - Use find_memory_block_by_id() in init_memory_block() to catch duplicates Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hildenbrand Cc: "mike.tra...@hpe.com" Cc: Andrew Morton Cc: Ing

[PATCH v3 08/11] mm/memory_hotplug: Drop MHP_MEMBLOCK_API

No longer needed, the callers of arch_add_memory() can handle this manually. Cc: Andrew Morton Cc: David Hildenbrand Cc: Michal Hocko Cc: Oscar Salvador Cc: Pavel Tatashin Cc: Wei Yang Cc: Joonsoo Kim Cc: Qian Cai Cc: Arun KS Cc: Mathieu Malaterre Signed-off-by: David Hildenbrand

[PATCH v3 02/11] s390x/mm: Fail when an altmap is used for arch_add_memory()

ZONE_DEVICE is not yet supported, fail if an altmap is passed, so we don't forget arch_add_memory()/arch_remove_memory() when unlocking support. Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Andrew Morton Cc: Michal Hocko Cc: Mike Rapoport Cc: David Hildenbrand Cc: Vasily Gorbik Cc: Oscar

[PATCH v3 03/11] s390x/mm: Implement arch_remove_memory()

Will come in handy when wanting to handle errors after arch_add_memory(). Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Andrew Morton Cc: Michal Hocko Cc: Mike Rapoport Cc: David Hildenbrand Cc: Vasily Gorbik Cc: Oscar Salvador Signed-off-by: David Hildenbrand --- arch/s390/mm/init.c

[PATCH v3 00/11] mm/memory_hotplug: Factor out memory block devicehandling

memory_block()" - Various changes to "mm/memory_hotplug: Create memory block devices after arch_add_memory()" and "mm/memory_hotplug: Create memory block devices after arch_add_memory()" due to switching from sections to block_id's. v1 -> v2: - s390x/mm: Implement

Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation

On 04.06.19 19:36, Robin Murphy wrote: > On 04/06/2019 07:56, David Hildenbrand wrote: >> On 03.06.19 23:41, Wei Yang wrote: >>> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote: >>>> A proper arch_remove_memory() implementation is on its way, which

Re: [PATCH v3 07/11] mm/memory_hotplug: Create memory block devices after arch_add_memory()

>> /* >> * For now, we have a linear search to go find the appropriate >> * memory_block corresponding to a particular phys_index. If >> @@ -658,6 +670,11 @@ static int init_memory_block(struct memory_block >> **memory, int block_id, >> unsigned long start_pfn; >> int ret = 0; >> >> +

Re: [PATCH v3 07/11] mm/memory_hotplug: Create memory block devices after arch_add_memory()

On 05.06.19 10:58, David Hildenbrand wrote: >>> /* >>> * For now, we have a linear search to go find the appropriate >>> * memory_block corresponding to a particular phys_index. If >>> @@ -658,6 +670,11 @@ static int init_memory_block(struct memo

Re: [PATCH v3 09/11] mm/memory_hotplug: Remove memory block devices before arch_remove_memory()

On 05.06.19 00:07, Wei Yang wrote: > On Mon, May 27, 2019 at 01:11:50PM +0200, David Hildenbrand wrote: >> Let's factor out removing of memory block devices, which is only >> necessary for memory added via add_memory() and friends that created >> memory block devices. Remo

Re: [PATCH v3 00/11] mm/memory_hotplug: Factor out memory block devicehandling

On 03.06.19 23:21, Wei Yang wrote: > IMHO, there is some typo. Yes, thanks. > > s/devicehandling/device handling/ > > On Mon, May 27, 2019 at 01:11:41PM +0200, David Hildenbrand wrote: >> We only want memory block devices for memory to be onlined/offlined >>

Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation

On 03.06.19 23:41, Wei Yang wrote: > On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote: >> A proper arch_remove_memory() implementation is on its way, which also >> cleanly removes page tables in arch_add_memory() in case something goes >> wrong. >

Re: [PATCH v3 06/11] mm/memory_hotplug: Allow arch_remove_pages() without CONFIG_MEMORY_HOTREMOVE

On 04.06.19 00:15, Wei Yang wrote: > Allow arch_remove_pages() or arch_remove_memory()? Looks like I merged __remove_pages() and arch_remove_memory(). @Andrew, can you fix this up to "mm/memory_hotplug: Allow arch_remove_memory() without CONFIG_MEMORY_HOTREMOVE" ? Thanks! > > And want to

Re: [PATCH v3 05/11] drivers/base/memory: Pass a block_id to init_memory_block()

On 03.06.19 23:49, Wei Yang wrote: > On Mon, May 27, 2019 at 01:11:46PM +0200, David Hildenbrand wrote: >> We'll rework hotplug_memory_register() shortly, so it no longer consumes >> pass a section. >> >> Cc: Greg Kroah-Hartman >> Cc: "Rafael J. Wysocki

Re: [PATCH v3 07/11] mm/memory_hotplug: Create memory block devices after arch_add_memory()

On 05.06.19 23:22, Wei Yang wrote: > On Wed, Jun 05, 2019 at 12:58:46PM +0200, David Hildenbrand wrote: >> On 05.06.19 10:58, David Hildenbrand wrote: >>>>> /* >>>>> * For now, we have a linear search to go find the appropriate >>>>> *

Re: [PATCH v3 06/11] mm/memory_hotplug: Allow arch_remove_pages() without CONFIG_MEMORY_HOTREMOVE

On 04.06.19 10:31, Wei Yang wrote: > On Tue, Jun 04, 2019 at 08:59:43AM +0200, David Hildenbrand wrote: >> On 04.06.19 00:15, Wei Yang wrote: >>> Allow arch_remove_pages() or arch_remove_memory()? >> >> Looks like I merged __remove_pages() and arch_remove_memory

Re: [PATCH v1 1/6] mm: Section numbers use the type "unsigned long"

On 14.06.19 21:00, Andrew Morton wrote: > On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand wrote: > >> We are using a mixture of "int" and "unsigned long". Let's make this >> consistent by using "unsigned long" everywhere.

[PATCH v2 3/6] mm: Make register_mem_sect_under_node() static

It is only used internally. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Keith Busch Cc: Oscar Salvador Signed-off-by: David Hildenbrand --- drivers/base/node.c | 3 ++- include/linux/node.h | 7 --- 2 files changed, 2 insertions(+), 8 deletions(-)

[PATCH v2 0/6] mm: Further memory block device cleanups

- Fix compilation error -- Get rid of the "hint" parameter completely David Hildenbrand (6): mm: Section numbers use the type "unsigned long" drivers/base/memory: Use "unsigned long" for block ids mm: Make register_mem_sect_under_node() static mm/memory_ho

[PATCH v2 2/6] drivers/base/memory: Use "unsigned long" for block ids

Block ids are just shifted section numbers, so let's also use "unsigned long" for them, too. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 22 +++--- 1 file changed, 11 insertions(+), 11 dele

[PATCH v2 6/6] drivers/base/memory.c: Get rid of find_memory_block_hinted()

No longer needed, let's remove it. Also, drop the "hint" parameter completely from "find_memory_block_by_id", as nobody needs it anymore. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Stephen Rothwell Cc: Pavel Tatashin Cc: "mike.tr

[PATCH v2 5/6] mm/memory_hotplug: Move and simplify walk_memory_blocks()

Let's move walk_memory_blocks() to the place where memory block logic resides and simplify it. While at it, add a type for the callback function. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hildenbrand Cc: Andrew Morton Cc: Stephen Rothwell Cc: Pavel Tatashin Cc: And

[PATCH v2 1/6] mm: Section numbers use the type "unsigned long"

k is an int. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Vlastimil Babka Cc: Michal Hocko Cc: Dan Williams Cc: Mel Gorman Cc: Wei Yang Cc: Johannes Weiner Cc: Arun KS Cc: Pavel Tatashin Cc: Oscar Salvador Cc: Stephen Rothwell Cc: Mike Rapoport

[PATCH v2 4/6] mm/memory_hotplug: Rename walk_memory_range() and pass start+size instead of pfns

the documentation. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: David Hildenbrand Cc: Rashmica Gupta Cc: Andrew Morton Cc: Pavel Tatashin Cc: Anshuman Khandual Cc: Michael Neuling Cc: Thomas Gl

[PATCH v3 0/6] mm: Further memory block device cleanups

uot; -- "unsigned long i" -> "unsigned long nr", in one case -> "int i" - "drivers/base/memory.c: Get rid of find_memory_block_hinted(" -- Fix compilation error -- Get rid of the "hint" parameter completely David Hildenbrand (6): mm: Sect

[PATCH v3 3/6] mm: Make register_mem_sect_under_node() static

It is only used internally. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Keith Busch Cc: Oscar Salvador Signed-off-by: David Hildenbrand --- drivers/base/node.c | 3 ++- include/linux/node.h | 7 --- 2 files changed, 2 insertions(+), 8 deletions(-)

[PATCH v3 1/6] mm: Section numbers use the type "unsigned long"

k is an int. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Vlastimil Babka Cc: Michal Hocko Cc: Dan Williams Cc: Mel Gorman Cc: Wei Yang Cc: Johannes Weiner Cc: Arun KS Cc: Pavel Tatashin Cc: Oscar Salvador Cc: Stephen Rothwell Cc: Mike Rapoport

[PATCH v3 4/6] mm/memory_hotplug: Rename walk_memory_range() and pass start+size instead of pfns

the documentation. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: David Hildenbrand Cc: Rashmica Gupta Cc: Andrew Morton Cc: Pavel Tatashin Cc: Anshuman Khandual Cc: Michael Neuling Cc: Thomas Gl

Re: [PATCH v2 6/6] drivers/base/memory.c: Get rid of find_memory_block_hinted()

On 20.06.19 12:35, David Hildenbrand wrote: > No longer needed, let's remove it. Also, drop the "hint" parameter > completely from "find_memory_block_by_id", as nobody needs it anymore. > > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Cc: An

[PATCH v3 2/6] drivers/base/memory: Use "unsigned long" for block ids

Block ids are just shifted section numbers, so let's also use "unsigned long" for them, too. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 22 +++--- 1 file changed, 11 insertions(+), 11 dele

[PATCH v3 6/6] drivers/base/memory.c: Get rid of find_memory_block_hinted()

No longer needed, let's remove it. Also, drop the "hint" parameter completely from "find_memory_block_by_id", as nobody needs it anymore. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Stephen Rothwell Cc: Pavel Tatashin Cc: "mike.tr

[PATCH v3 5/6] mm/memory_hotplug: Move and simplify walk_memory_blocks()

Let's move walk_memory_blocks() to the place where memory block logic resides and simplify it. While at it, add a type for the callback function. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hildenbrand Cc: Andrew Morton Cc: Stephen Rothwell Cc: Pavel Tatashin Cc: And

Re: [PATCH v2 4/6] mm/memory_hotplug: Rename walk_memory_range() and pass start+size instead of pfns

On 20.06.19 18:05, Nathan Chancellor wrote: > On Thu, Jun 20, 2019 at 12:35:18PM +0200, David Hildenbrand wrote: >> walk_memory_range() was once used to iterate over sections. Now, it >> iterates over memory blocks. Rename the function, fixup the >> documentation. Also, pa

Re: [PATCH v3 0/6] mm: Further memory block device cleanups

On 21.06.19 17:15, Qian Cai wrote: > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote: >> @Andrew: Only patch 1, 4 and 6 changed compared to v1. >> >> Some further cleanups around memory block devices. Especially, clean up >> and simplify walk_memory_range().

Re: [PATCH v3 5/6] mm/memory_hotplug: Move and simplify walk_memory_blocks()

On 20.06.19 20:31, David Hildenbrand wrote: > Let's move walk_memory_blocks() to the place where memory block logic > resides and simplify it. While at it, add a type for the callback function. > > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Cc: David Hild

Re: [PATCH v3 0/6] mm: Further memory block device cleanups

On 21.06.19 17:15, Qian Cai wrote: > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote: >> @Andrew: Only patch 1, 4 and 6 changed compared to v1. >> >> Some further cleanups around memory block devices. Especially, clean up >> and simplify walk_memory_range().

Re: [PATCH v3 0/6] mm: Further memory block device cleanups

On 21.06.19 21:07, Qian Cai wrote: > On Fri, 2019-06-21 at 20:56 +0200, David Hildenbrand wrote: >> On 21.06.19 20:24, David Hildenbrand wrote: >>> On 21.06.19 17:15, Qian Cai wrote: >>>> On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote: >>>&g

Re: [PATCH v3 0/6] mm: Further memory block device cleanups

On 21.06.19 20:24, David Hildenbrand wrote: > On 21.06.19 17:15, Qian Cai wrote: >> On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote: >>> @Andrew: Only patch 1, 4 and 6 changed compared to v1. >>> >>> Some further cleanups around memory

Re: [next][PowerPC] RCU stalls while booting linux-next on PowerVM LPAR

On 24.06.19 16:09, Sachin Sant wrote: > Latest -next fails to boot on POWER9 PowerVM LPAR due to RCU stalls. > > This problem was introduced with next-20190620 (dc636f5d78). > next-20190619 was last good kernel. > > Reverting following commit allows the kernel to boot. > 2fd4aeea6b603 :

Re: [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API

On 09.05.19 01:08, osalvador wrote: > On Wed, 2019-05-08 at 09:39 +0200, David Hildenbrand wrote: >> However I haven't really thought it through yet, smalles like that >> could >> as well just be handled by the caller of >> arch_add_memory()/arch_remove_memory()

Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

On 09.05.19 14:43, Wei Yang wrote: > On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote: >> Only memory to be added to the buddy and to be onlined/offlined by >> user space using memory block devices needs (and should have!) memory >> block devices. >

Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

On 09.05.19 15:55, Wei Yang wrote: > On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote: >> Only memory to be added to the buddy and to be onlined/offlined by >> user space using memory block devices needs (and should have!) memory >> block devices. >

Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

On 09.05.19 16:31, Wei Yang wrote: > On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote: >> Only memory to be added to the buddy and to be onlined/offlined by >> user space using memory block devices needs (and should have!) memory >> block devices. >

Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

> Looks good to me. > >> >> (I would actually even prefer "memory_block_devices", because memory >> blocks have different meanins) >> > > Agree with you, this comes to my mind sometime ago :-) We have memblocks, memory_blocks ... I guess memory_block_device is unique :) > >>> >>> [...] >>>

[PATCH v2 0/8] mm/memory_hotplug: Factor out memory block device handling

mory. I am thinking about remove_pfn_range_from_zone()", du undo everything "move_pfn_range_to_zone()" did. v1 -> v2: - s390x/mm: Implement arch_remove_memory() -- remove mapping after "__remove_pages" David Hildenbrand (8): mm/memory_hotplug: Simplify and fix c

[PATCH v2 2/8] s390x/mm: Implement arch_remove_memory()

Will come in handy when wanting to handle errors after arch_add_memory(). Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Andrew Morton Cc: Michal Hocko Cc: Mike Rapoport Cc: David Hildenbrand Cc: Vasily Gorbik Cc: Oscar Salvador Signed-off-by: David Hildenbrand --- arch/s390/mm/init.c

Re: [PATCH v2 0/8] mm/memory_hotplug: Factor out memory block device handling

On 07.05.19 21:04, Dan Williams wrote: > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: >> >> We only want memory block devices for memory to be onlined/offlined >> (add/remove from the buddy). This is required so user space can >> online/offline memory an

[PATCH v2 8/8] mm/memory_hotplug: Remove "zone" parameter from sparse_remove_one_section

Unused, and memory unplug path should never care about zones. This is the job of memory offlining. ZONE_DEVICE might require special care - the caller of arch_remove_memory() should handle this. Signed-off-by: David Hildenbrand --- include/linux/memory_hotplug.h | 2 +- mm/memory_hotplug.c

[PATCH v2 1/8] mm/memory_hotplug: Simplify and fix check_hotplug_memory_range()

By converting start and size to page granularity, we actually ignore unaligned parts within a page instead of properly bailing out with an error. Cc: Andrew Morton Cc: Oscar Salvador Cc: Michal Hocko Cc: David Hildenbrand Cc: Pavel Tatashin Cc: Qian Cai Cc: Wei Yang Cc: Arun KS Cc

[PATCH v2 6/8] mm/memory_hotplug: Remove memory block devices before arch_remove_memory()

() and arch_remove_memory(). Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hildenbrand Cc: "mike.tra...@hpe.com" Cc: Andrew Morton Cc: Andrew Banman Cc: Ingo Molnar Cc: Alex Deucher Cc: "David S. Miller" Cc: Mark Brown Cc: Chris Wilson Cc: Oscar Salv

[PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

, because it is now effectively stale. Only after memory block devices have been added, memory can be onlined by user space. This implies, that memory is not visible to user space at all before arch_add_memory() succeeded. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: David Hilde

[PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG

uot;H. Peter Anvin" Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Michal Hocko Cc: Mike Rapoport Cc: David Hildenbrand Cc: Oscar Salvador Cc: "Kirill A. Shutemov" Cc: Alex Deucher Cc: "David S. Miller" Cc: Mark Brown Cc: Chris Wi

[PATCH v2 7/8] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail

ced off and never removed. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Alex Deucher Cc: "David S. Miller" Cc: Mark Brown Cc: Chris Wilson Cc: David Hildenbrand Cc: Oscar Salvador Cc: Andrew Morton Cc: Jonathan Cameron Signed-off-by: David Hildenbrand --- dr

[PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API

No longer needed, the callers of arch_add_memory() can handle this manually. Cc: Andrew Morton Cc: David Hildenbrand Cc: Michal Hocko Cc: Oscar Salvador Cc: Pavel Tatashin Cc: Wei Yang Cc: Joonsoo Kim Cc: Qian Cai Cc: Arun KS Cc: Mathieu Malaterre Signed-off-by: David Hildenbrand

Re: [PATCH v2 0/8] mm/memory_hotplug: Factor out memory block device handling

On 07.05.19 21:21, David Hildenbrand wrote: > On 07.05.19 21:04, Dan Williams wrote: >> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: >>> >>> We only want memory block devices for memory to be onlined/offlined >>> (add/remove from the buddy)

Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()

>> +static void unregister_memory(struct memory_block *memory) >> +{ >> + BUG_ON(memory->dev.bus != _subsys); > > Given this should never happen and only a future kernel developer > might trip over it, do we really need to kill that developer's > machine? I.e. s/BUG/WARN/? I guess an

Re: [PATCH v2 3/8] mm/memory_hotplug: arch_remove_memory() and __remove_pages() with CONFIG_MEMORY_HOTPLUG

On 07.05.19 23:02, Dan Williams wrote: > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: >> >> Let's prepare for better error handling while adding memory by allowing >> to use arch_remove_memory() and __remove_pages() even if >> CONFIG_

Re: [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API

On 07.05.19 23:19, Dan Williams wrote: > On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote: >> >> No longer needed, the callers of arch_add_memory() can handle this >> manually. >> >> Cc: Andrew Morton >> Cc: David Hildenbrand >> Cc: Mich

<    1   2   3   4   5   6   7   8   9   10   >