Re: [PATCH v3 5/9] mm: remove CONFIG_DISCONTIGMEM
On Fri, Jun 11, 2021 at 01:53:48PM -0700, Stephen Brennan wrote:
> Mike Rapoport writes:
> > From: Mike Rapoport
> >
> > There are no architectures that support DISCONTIGMEM left.
> >
> > Remove the configuration option and the dead code it was guarding in the
> > generic memory management code.
> >
> > Signed-off-by: Mike Rapoport
> > ---
> > include/asm-generic/memory_model.h | 37 --
> > include/linux/mmzone.h | 8 ---
> > mm/Kconfig | 25 +++-
> > mm/page_alloc.c| 13 ---
> > 4 files changed, 12 insertions(+), 71 deletions(-)
> >
> > diff --git a/include/asm-generic/memory_model.h
> > b/include/asm-generic/memory_model.h
> > index 7637fb46ba4f..a2c8ed60233a 100644
> > --- a/include/asm-generic/memory_model.h
> > +++ b/include/asm-generic/memory_model.h
> > @@ -6,47 +6,18 @@
> >
> > #ifndef __ASSEMBLY__
> >
> > +/*
> > + * supports 3 memory models.
> > + */
>
> This comment could either be updated to reflect 2 memory models, or
> removed entirely.
I counted SPARSE and SPARSE_VMEMMAP as 2.
The code below has three clauses: one for FLATMEM, one for SPARSE and one
for VMEMMAP.
> Thanks,
> Stephen
>
> > #if defined(CONFIG_FLATMEM)
> >
> > #ifndef ARCH_PFN_OFFSET
> > #define ARCH_PFN_OFFSET(0UL)
> > #endif
> >
> > -#elif defined(CONFIG_DISCONTIGMEM)
> > -
> > -#ifndef arch_pfn_to_nid
> > -#define arch_pfn_to_nid(pfn) pfn_to_nid(pfn)
> > -#endif
> > -
> > -#ifndef arch_local_page_offset
> > -#define arch_local_page_offset(pfn, nid) \
> > - ((pfn) - NODE_DATA(nid)->node_start_pfn)
> > -#endif
> > -
> > -#endif /* CONFIG_DISCONTIGMEM */
> > -
> > -/*
> > - * supports 3 memory models.
> > - */
> > -#if defined(CONFIG_FLATMEM)
> > -
> > #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
> > #define __page_to_pfn(page)((unsigned long)((page) - mem_map) + \
> > ARCH_PFN_OFFSET)
> > -#elif defined(CONFIG_DISCONTIGMEM)
> > -
> > -#define __pfn_to_page(pfn) \
> > -({ unsigned long __pfn = (pfn);\
> > - unsigned long __nid = arch_pfn_to_nid(__pfn); \
> > - NODE_DATA(__nid)->node_mem_map + arch_local_page_offset(__pfn, __nid);\
> > -})
> > -
> > -#define __page_to_pfn(pg) \
> > -({ const struct page *__pg = (pg); \
> > - struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg)); \
> > - (unsigned long)(__pg - __pgdat->node_mem_map) + \
> > -__pgdat->node_start_pfn; \
> > -})
> >
> > #elif defined(CONFIG_SPARSEMEM_VMEMMAP)
> >
> > @@ -70,7 +41,7 @@
> > struct mem_section *__sec = __pfn_to_section(__pfn);\
> > __section_mem_map_addr(__sec) + __pfn; \
> > })
> > -#endif /* CONFIG_FLATMEM/DISCONTIGMEM/SPARSEMEM */
> > +#endif /* CONFIG_FLATMEM/SPARSEMEM */
> >
> > /*
> > * Convert a physical address to a Page Frame Number and back
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 0d53eba1c383..700032e99419 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -738,10 +738,12 @@ struct zonelist {
> > struct zoneref _zonerefs[MAX_ZONES_PER_ZONELIST + 1];
> > };
> >
> > -#ifndef CONFIG_DISCONTIGMEM
> > -/* The array of struct pages - for discontigmem use pgdat->lmem_map */
> > +/*
> > + * The array of struct pages for flatmem.
> > + * It must be declared for SPARSEMEM as well because there are
> > configurations
> > + * that rely on that.
> > + */
> > extern struct page *mem_map;
> > -#endif
> >
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > struct deferred_split {
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 02d44e3420f5..218b96ccc84a 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -19,7 +19,7 @@ choice
> >
> > config FLATMEM_MANUAL
> > bool "Flat Memory"
> > - depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) ||
> > ARCH_FLATMEM_ENABLE
> > + depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE
> > help
> > This option is best suited for non-NUMA systems with
> > flat address space. The FLATMEM is the most efficient
> > @@ -32,21 +32,6 @@ config FLATMEM_MANUAL
> >
> > If unsure, choose this option (Flat Memory) over any other.
> >
> > -config DISCONTIGMEM_MANUAL
> > - bool "Discontiguous Memory"
> > - depends on ARCH_DISCONTIGMEM_ENABLE
> > - help
> > - This option provides enhanced support for discontiguous
> > - memory systems, over FLATMEM. These systems have holes
> > - in their physical address spaces, and this option provides
> > - more efficient handling of these holes.
> > -
> > - Although "Discontiguous Memory" is still used by several
> > - architectures, it is considered deprecated in favor of
> > - "Sparse Memory".
> > -
> > - If unsure,
Re: [PATCH v1 0/2] firmware: dmi_scan: Make it work in kexec'ed kernel
> Probably it is doable to have kexec on 32bit efi working
> without runtime service support, that means no need the trick of fixed
> mapping.
>
> If I can restore my vm to boot 32bit efi on this weekend then I may provide
> some draft
> patches for test.
Unfortunately I failed to setup a 32bit efi guest, here are some
untested draft patches, please have a try.
= kernel draft patch ==
---
arch/x86/boot/header.S |2 +-
arch/x86/platform/efi/efi.c|6 +++---
arch/x86/platform/efi/quirks.c |3 ---
3 files changed, 4 insertions(+), 7 deletions(-)
--- linux-x86.orig/arch/x86/boot/header.S
+++ linux-x86/arch/x86/boot/header.S
@@ -416,7 +416,7 @@ xloadflags:
# define XLF23 0
#endif
-#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC_CORE)
+#if defined(CONFIG_EFI) && defined(CONFIG_KEXEC_CORE)
# define XLF4 XLF_EFI_KEXEC
#else
# define XLF4 0
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++ linux-x86/arch/x86/platform/efi/efi.c
@@ -710,10 +710,10 @@ static void __init kexec_enter_virtual_m
unsigned int num_pages;
/*
-* We don't do virtual mode, since we don't do runtime services, on
-* non-native EFI.
+* We don't do virtual mode, since we don't do runtime services
+* on non-native or IA32 EFI.
*/
- if (efi_is_mixed()) {
+ if (!efi_enabled(EFI_64BIT)) {
efi_memmap_unmap();
clear_bit(EFI_RUNTIME_SERVICES, );
return;
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -524,9 +524,6 @@ int __init efi_reuse_config(u64 tables,
if (!efi_setup)
return 0;
- if (!efi_enabled(EFI_64BIT))
- return 0;
-
data = early_memremap(efi_setup, sizeof(*data));
if (!data) {
ret = -ENOMEM;
= kexec-tools draft patch =
---
kexec/arch/i386/kexec-bzImage.c |5 +
1 file changed, 5 insertions(+)
--- kexec-tools.orig/kexec/arch/i386/kexec-bzImage.c
+++ kexec-tools/kexec/arch/i386/kexec-bzImage.c
@@ -83,6 +83,11 @@ int bzImage_probe(const char *buf, off_t
if (probe_debug) {
fprintf(stderr, "It's a bzImage\n");
}
+
+#define XLF_EFI_KEXEC (1 << 4)
+ if ((header->xloadflags & XLF_EFI_KEXEC) == XLF_EFI_KEXEC)
+ bzImage_support_efi_boot = 1;
+
return 0;
}
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 5/9] mm: remove CONFIG_DISCONTIGMEM
Mike Rapoport writes:
> From: Mike Rapoport
>
> There are no architectures that support DISCONTIGMEM left.
>
> Remove the configuration option and the dead code it was guarding in the
> generic memory management code.
>
> Signed-off-by: Mike Rapoport
> ---
> include/asm-generic/memory_model.h | 37 --
> include/linux/mmzone.h | 8 ---
> mm/Kconfig | 25 +++-
> mm/page_alloc.c| 13 ---
> 4 files changed, 12 insertions(+), 71 deletions(-)
>
> diff --git a/include/asm-generic/memory_model.h
> b/include/asm-generic/memory_model.h
> index 7637fb46ba4f..a2c8ed60233a 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -6,47 +6,18 @@
>
> #ifndef __ASSEMBLY__
>
> +/*
> + * supports 3 memory models.
> + */
This comment could either be updated to reflect 2 memory models, or
removed entirely.
Thanks,
Stephen
> #if defined(CONFIG_FLATMEM)
>
> #ifndef ARCH_PFN_OFFSET
> #define ARCH_PFN_OFFSET (0UL)
> #endif
>
> -#elif defined(CONFIG_DISCONTIGMEM)
> -
> -#ifndef arch_pfn_to_nid
> -#define arch_pfn_to_nid(pfn) pfn_to_nid(pfn)
> -#endif
> -
> -#ifndef arch_local_page_offset
> -#define arch_local_page_offset(pfn, nid) \
> - ((pfn) - NODE_DATA(nid)->node_start_pfn)
> -#endif
> -
> -#endif /* CONFIG_DISCONTIGMEM */
> -
> -/*
> - * supports 3 memory models.
> - */
> -#if defined(CONFIG_FLATMEM)
> -
> #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
> #define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
>ARCH_PFN_OFFSET)
> -#elif defined(CONFIG_DISCONTIGMEM)
> -
> -#define __pfn_to_page(pfn) \
> -({ unsigned long __pfn = (pfn);\
> - unsigned long __nid = arch_pfn_to_nid(__pfn); \
> - NODE_DATA(__nid)->node_mem_map + arch_local_page_offset(__pfn, __nid);\
> -})
> -
> -#define __page_to_pfn(pg)\
> -({ const struct page *__pg = (pg); \
> - struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg)); \
> - (unsigned long)(__pg - __pgdat->node_mem_map) + \
> - __pgdat->node_start_pfn; \
> -})
>
> #elif defined(CONFIG_SPARSEMEM_VMEMMAP)
>
> @@ -70,7 +41,7 @@
> struct mem_section *__sec = __pfn_to_section(__pfn);\
> __section_mem_map_addr(__sec) + __pfn; \
> })
> -#endif /* CONFIG_FLATMEM/DISCONTIGMEM/SPARSEMEM */
> +#endif /* CONFIG_FLATMEM/SPARSEMEM */
>
> /*
> * Convert a physical address to a Page Frame Number and back
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0d53eba1c383..700032e99419 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -738,10 +738,12 @@ struct zonelist {
> struct zoneref _zonerefs[MAX_ZONES_PER_ZONELIST + 1];
> };
>
> -#ifndef CONFIG_DISCONTIGMEM
> -/* The array of struct pages - for discontigmem use pgdat->lmem_map */
> +/*
> + * The array of struct pages for flatmem.
> + * It must be declared for SPARSEMEM as well because there are configurations
> + * that rely on that.
> + */
> extern struct page *mem_map;
> -#endif
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> struct deferred_split {
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 02d44e3420f5..218b96ccc84a 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -19,7 +19,7 @@ choice
>
> config FLATMEM_MANUAL
> bool "Flat Memory"
> - depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) ||
> ARCH_FLATMEM_ENABLE
> + depends on !ARCH_SPARSEMEM_ENABLE || ARCH_FLATMEM_ENABLE
> help
> This option is best suited for non-NUMA systems with
> flat address space. The FLATMEM is the most efficient
> @@ -32,21 +32,6 @@ config FLATMEM_MANUAL
>
> If unsure, choose this option (Flat Memory) over any other.
>
> -config DISCONTIGMEM_MANUAL
> - bool "Discontiguous Memory"
> - depends on ARCH_DISCONTIGMEM_ENABLE
> - help
> - This option provides enhanced support for discontiguous
> - memory systems, over FLATMEM. These systems have holes
> - in their physical address spaces, and this option provides
> - more efficient handling of these holes.
> -
> - Although "Discontiguous Memory" is still used by several
> - architectures, it is considered deprecated in favor of
> - "Sparse Memory".
> -
> - If unsure, choose "Sparse Memory" over this option.
> -
> config SPARSEMEM_MANUAL
> bool "Sparse Memory"
> depends on ARCH_SPARSEMEM_ENABLE
> @@ -62,17 +47,13 @@ config SPARSEMEM_MANUAL
>
> endchoice
>
> -config DISCONTIGMEM
> - def_bool y
> - depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) ||
> DISCONTIGMEM_MANUAL
> -
> config SPARSEMEM
> def_bool y
> depends on
Re: Compiling makedumpfile from source
-Original Message- > When i try to makedumpfile without vmcorefile, it complains that > "/tmp/vmcoreinfo no such file or directory" and fails to collect the dump. > > From the README it appears to me that makedumpfile can get vmcoreinfo > from /proc/vmcore > Is there any special CONFIG needed to support this? hmm, at least CONFIG_CRASH_CORE=y would be needed. Kazu ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: Compiling makedumpfile from source
When i try to makedumpfile without vmcorefile, it complains that
"/tmp/vmcoreinfo no such file or directory" and fails to collect the dump.
From the README it appears to me that makedumpfile can get vmcoreinfo
from /proc/vmcore
Is there any special CONFIG needed to support this?
Thank you in advance!
Regards,
Manty
On Fri, Jun 11, 2021 at 2:27 PM manty kuma wrote:
>
> > libdw-dev libelf-dev zlib1g-dev libbz2-dev
> These packages helped. I am able to compile both elfutils and makedumpfile
> now.
> Thank you.
>
> Just one more question I have.
>
> I am using linux kernel v5.10
> Is it necessary to generate a "vmcoreinfo" file before hand and provide it to
> `makedumpfile`? or can it get ir from `/proc/vmcore`?
>
> Regards,
> Manty
>
> On Fri, Jun 11, 2021 at 2:00 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>>
>> -Original Message-
>> > Thank you.
>> > for example, i am trying to compile: elfutils-0.182 package downloaded
>> > from https://sourceware.org/elfutils/ftp/0.182/
>> > After successfully configuring it, make fails with following error.
>>
>> Ah, I thought by mistake that you failed to compile makedumpfile.
>> Probably you should ask it to the elfutils community.
>>
>> btw, if you can use makedumpfile with dynamic libraries, maybe you
>> can use the distribution's packages without building elfutils.
>> I'm not familiar with Debian/Ubuntu, but I built a makedumpfile on
>> an Ubuntu machine once with the following packages:
>> libdw-dev libelf-dev zlib1g-dev libbz2-dev
>> and "make LINKTYPE=dynamic", please see FAQ.002 in README.
>>
>> Kazu
>>
>> >
>> >
>> > Making all in libdwfl
>> > CC zstd.o
>> > In file included from zstd.c:4:0:
>> > gzip.c: In function ‘__libdw_unzstd’:
>> > gzip.c:278:39: error: passing argument 1 of ‘ZSTD_decompressStream’
>> > from incompatible pointer type [-Werror=incompatible-pointer-types]
>> >result = ZSTD_decompressStream (dctx, , );
>> >^~~~
>> > In file included from gzip.c:53:0,
>> > from zstd.c:4:
>> > /usr/include/zstd.h:308:20: note: expected ‘ZSTD_DStream * {aka struct
>> > ZSTD_DStream_s *}’ but argument is of type ‘ZSTD_DCtx * {aka struct
>> > ZSTD_DCtx_s *}’
>> > ZSTDLIB_API size_t ZSTD_decompressStream(ZSTD_DStream* zds,
>> > ZSTD_outBuffer* output, ZSTD_inBuffer* input);
>> > ^
>> > cc1: all warnings being treated as errors
>> > Makefile:681: recipe for target 'zstd.o' failed
>> > make[2]: *** [zstd.o] Error 1
>> >
>> >
>> > Seems like the configure file is not checking for specific version of
>> > libzstd-dev and it is not compatible with my current libzstd-dev
>> > My current version is as follows:
>> > ---
>> > $ apt-show-versions libzstd-dev
>> > libzstd-dev:amd64/stretch 1.1.2-1+deb9u1 uptodate
>> > ---
>> >
>> > Thank you.
>> >
>> > Regards,
>> > Manty
>> > On Fri, Jun 11, 2021 at 10:13 AM HAGIO KAZUHITO(萩尾 一仁)
>> > wrote:
>> > >
>> > > Hi Manty,
>> > >
>> > > -Original Message-
>> > > > What version of elfutils is needed by `makedumpfile`?
>> > > > elfutils-0.144 is mentioned in README.
>> > > > I tried this one but the compilation is broken.
>> > > >
>> > > > https://sourceware.org/elfutils/ftp/0.144/
>> > > >
>> > > > Should I try to use the latest one instead?
>> > >
>> > > It could be built with elfutils-0.144 or later at the point of v1.6.7,
>> > > and
>> > > I can build the latest makedumpfile with elfutils-0.148, 0.164, 0.182 on
>> > > some RHEL environments on hand with "make LINKTYPE=dynamic".
>> > >
>> > > What command do you use to build? and what error do you see?
>> > >
>> > > Thanks,
>> > > Kazu
>> > >
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
