Looking into why we still create memblocks for hotplugged memory (via
add_memory()), I discovered that we might not need ARCH_KEEP_MEMBLOCK on
s390x after all.
After [1] we will no longer create memblocks for hotplugged memory in
case of !CONFIG_ARCH_KEEP_MEMBLOCK. With this series, the same will apply
to standby memory on s390x, added via add_memory().
[1] https://lkml.kernel.org/r/[email protected]
David Hildenbrand (2):
s390/zcore: traverse resources instead of memblocks
s390/mm: don't set ARCH_KEEP_MEMBLOCK
arch/s390/Kconfig | 1 -
drivers/s390/char/zcore.c | 61 ++++++++++++++++++++++++++++++---------
2 files changed, 48 insertions(+), 14 deletions(-)
--
2.25.1
Commit 50be63450728 ("s390/mm: Convert bootmem to memblock") mentions
"The original bootmem allocator is getting replaced by memblock. To
cover the needs of the s390 kdump implementation the physical
memory list is used."
zcore was converted to use resources instead of memblocks.
memblock_discard() will *not* mess with "physmem", only with "memory" and
"reserved" memblocks. So, that data will stay after early boot, to be
used in arch/s390/kernel/crash_dump.c to create the ELF header from
inside the 2nd (a.k.a. dumping) kernel.
We no longer need ARCH_KEEP_MEMBLOCK.
Cc: Heiko Carstens <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Cc: Philipp Rudo <[email protected]>
Cc: Michael Holzheu <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
---
arch/s390/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 8206b2c19aa8..122bf4cad8a5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -102,7 +102,6 @@ config S390
select ARCH_INLINE_WRITE_UNLOCK_BH
select ARCH_INLINE_WRITE_UNLOCK_IRQ
select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
- select ARCH_KEEP_MEMBLOCK
select ARCH_STACKWALK
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_NUMA_BALANCING
--
2.25.1
On 17.04.20 17:01, David Hildenbrand wrote:
> Looking into why we still create memblocks for hotplugged memory (via
> add_memory()), I discovered that we might not need ARCH_KEEP_MEMBLOCK on
> s390x after all.
>
> After [1] we will no longer create memblocks for hotplugged memory in
> case of !CONFIG_ARCH_KEEP_MEMBLOCK. With this series, the same will apply
> to standby memory on s390x, added via add_memory().
>
> [1] https://lkml.kernel.org/r/[email protected]
>
> David Hildenbrand (2):
> s390/zcore: traverse resources instead of memblocks
> s390/mm: don't set ARCH_KEEP_MEMBLOCK
>
> arch/s390/Kconfig | 1 -
> drivers/s390/char/zcore.c | 61 ++++++++++++++++++++++++++++++---------
> 2 files changed, 48 insertions(+), 14 deletions(-)
>
Ping.
--
Thanks,
David / dhildenb
On Fri, Apr 17, 2020 at 05:01:51PM +0200, David Hildenbrand wrote:
> Commit 50be63450728 ("s390/mm: Convert bootmem to memblock") mentions
> "The original bootmem allocator is getting replaced by memblock. To
> cover the needs of the s390 kdump implementation the physical
> memory list is used."
>
> zcore was converted to use resources instead of memblocks.
> memblock_discard() will *not* mess with "physmem", only with "memory" and
> "reserved" memblocks. So, that data will stay after early boot, to be
> used in arch/s390/kernel/crash_dump.c to create the ELF header from
> inside the 2nd (a.k.a. dumping) kernel.
>
> We no longer need ARCH_KEEP_MEMBLOCK.
>
> Cc: Heiko Carstens <[email protected]>
> Cc: Vasily Gorbik <[email protected]>
> Cc: Christian Borntraeger <[email protected]>
> Cc: Philipp Rudo <[email protected]>
> Cc: Michael Holzheu <[email protected]>
> Signed-off-by: David Hildenbrand <[email protected]>
> ---
> arch/s390/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks!
On 29.06.20 14:44, Heiko Carstens wrote:
> On Fri, Jun 26, 2020 at 06:32:15PM +0200, Heiko Carstens wrote:
>> On Fri, Apr 17, 2020 at 05:01:51PM +0200, David Hildenbrand wrote:
>>> Commit 50be63450728 ("s390/mm: Convert bootmem to memblock") mentions
>>> "The original bootmem allocator is getting replaced by memblock. To
>>> cover the needs of the s390 kdump implementation the physical
>>> memory list is used."
>>>
>>> zcore was converted to use resources instead of memblocks.
>>> memblock_discard() will *not* mess with "physmem", only with "memory" and
>>> "reserved" memblocks. So, that data will stay after early boot, to be
>>> used in arch/s390/kernel/crash_dump.c to create the ELF header from
>>> inside the 2nd (a.k.a. dumping) kernel.
>>>
>>> We no longer need ARCH_KEEP_MEMBLOCK.
>>>
>>> Cc: Heiko Carstens <[email protected]>
>>> Cc: Vasily Gorbik <[email protected]>
>>> Cc: Christian Borntraeger <[email protected]>
>>> Cc: Philipp Rudo <[email protected]>
>>> Cc: Michael Holzheu <[email protected]>
>>> Signed-off-by: David Hildenbrand <[email protected]>
>>> ---
>>> arch/s390/Kconfig | 1 -
>>> 1 file changed, 1 deletion(-)
>>
>> Applied, thanks!
>
> Hmm, this triggers:
Ah, I see, will have a look. Weird I didn't notice that ...
Thanks!
--
Thanks,
David / dhildenb
On Fri, Jun 26, 2020 at 06:32:15PM +0200, Heiko Carstens wrote:
> On Fri, Apr 17, 2020 at 05:01:51PM +0200, David Hildenbrand wrote:
> > Commit 50be63450728 ("s390/mm: Convert bootmem to memblock") mentions
> > "The original bootmem allocator is getting replaced by memblock. To
> > cover the needs of the s390 kdump implementation the physical
> > memory list is used."
> >
> > zcore was converted to use resources instead of memblocks.
> > memblock_discard() will *not* mess with "physmem", only with "memory" and
> > "reserved" memblocks. So, that data will stay after early boot, to be
> > used in arch/s390/kernel/crash_dump.c to create the ELF header from
> > inside the 2nd (a.k.a. dumping) kernel.
> >
> > We no longer need ARCH_KEEP_MEMBLOCK.
> >
> > Cc: Heiko Carstens <[email protected]>
> > Cc: Vasily Gorbik <[email protected]>
> > Cc: Christian Borntraeger <[email protected]>
> > Cc: Philipp Rudo <[email protected]>
> > Cc: Michael Holzheu <[email protected]>
> > Signed-off-by: David Hildenbrand <[email protected]>
> > ---
> > arch/s390/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
>
> Applied, thanks!
Hmm, this triggers:
WARNING: modpost: vmlinux.o(.text+0x1e7c2): Section mismatch in reference from the function elfcorehdr_alloc() to the variable .meminit.data:memblock
The function elfcorehdr_alloc() references
the variable __meminitdata memblock.
This is often because elfcorehdr_alloc lacks a __meminitdata
annotation or the annotation of memblock is wrong.
WARNING: modpost: vmlinux.o(.text+0x1e800): Section mismatch in reference from the function elfcorehdr_alloc() to the function .meminit.text:__next_mem_range()
The function elfcorehdr_alloc() references
the function __meminit __next_mem_range().
This is often because elfcorehdr_alloc lacks a __meminit
annotation or the annotation of __next_mem_range is wrong.
WARNING: modpost: vmlinux.o(.text+0x1e844): Section mismatch in reference from the function elfcorehdr_alloc() to the function .meminit.text:__next_mem_range()
The function elfcorehdr_alloc() references
the function __meminit __next_mem_range().
This is often because elfcorehdr_alloc lacks a __meminit
annotation or the annotation of __next_mem_range is wrong.
So, reverted again ;)