Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On 10/27/22 at 02:28pm, Eric DeVolder wrote: > > > On 10/27/22 08:52, Baoquan He wrote: > > On 10/26/22 at 04:54pm, David Hildenbrand wrote: > > > On 26.10.22 16:48, Baoquan He wrote: > > > > On 10/25/22 at 12:31pm, Borislav Petkov wrote: > > > > > On Thu, Oct 13, 2022 at 10:57:28AM +0800, Baoquan He wrote: > > > > > > The concern to range number mainly is on Virt guest systems. > > > > > > > > > > And why would virt emulate 1K hotpluggable DIMM slots and not emulate > > > > > a > > > > > real machine? > > > > > > IIRC, ACPI only allows for 256 slots. PPC dlpar might provide more. > > > > > > > > > > > Well, currently, mem hotpug is an important feature on virt system to > > > > dynamically increase/shrink memory on the system. If only emulating real > > > > machine, it won't be different than bare metal system. > > > > > > > > IIRC, the ballon driver or virtio-mem feature can add memory board, e.g > > > > 1G, block size is 128M, 8 blocks added. When shrinking this 1G memory > > > > later, it will take best effort way to hot remove memory. Means if any > > > > memory block is occupied, it will be kept there. Finally we could only > > > > remove every second blocks, 4 blocks altogether. Then the left > > > > un-removed blocks will produce 4 separate memory regions. Like this, a > > > > virt guest could have many memory regions in kernel after memory > > > > being added/removed. > > > > > > > > If I am wrong, Please correct me, David. > > > > > > Yes, virtio-mem (but also PPC dlpar) can result in many individual memory > > > blocks with holes in between after hotunplug. Hotplug OTOH, usually tries > > > to > > > "plug" these holes and reduce the total number of memory blocks. It might > > > be > > > rare that our range will be heavily fragmented after unplug, but it's > > > certainly possible. > > > > > > [...] > > > > > > > > > > > Yes, now assume we have a HPE SGI system and it has memory hotplug > > > > capacity. The system itself has already got memory regions more than > > > > 1024. Then when we hot add extra memory board, we want to include the > > > > newly added memory regions into elfcorehdr so that it will be dumped out > > > > in kdump kernel. > > > > > > > > That's why I earlier suggested 2048 for number of memory regions. > > > > > > The more the better, unless "it hurts". Assuming a single memory block is > > > 128 MiB, that would be 256 GiB. > > > > > > Usually, on big systems, the memory block size is 2 GiB. So 4 TiB. > > > > Thanks a lot for these valuable inputs, David. > > > > Hi Boris, Eric > > > > So what's your suggested value for the Kconfig option? > > > > 1) cpu number, 1024? > > 2) memory regions, 2048? > > > > About below draft, any comment? We can decide a value based on our > > knowledge, can adjust later if any real system has more than the number. > > > > +config CRASH_ELF_CORE_PHDRS_NUM > > + depends on CRASH_DUMP && KEXEC_FILE && (HOTPLUG_CPU || > > MEMORY_HOTPLUG) > > + int > > + default 3072 > > + help > > + For the kexec_file_load path, specify the default number of > > + phdr for the vmcore. E.g the memory regions represented by the > > + 'System RAM' entries in /proc/iomem, the cpu notes of each > > + present cpu stored in /sys/devices/system/cpu/cpuX/crash_notes. > > > > Thanks > > Baoquan > > > > I prefer to keep CRASH_MAX_MEMORY_RANGES, as explained in my response to your > message on October 26. > eric Ah, sorry, I mixed it up with NR_CPUS. I went on an office outing yesterday, glad to see you and Boris have made an agreement on the code change and value. Thanks. > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Fri, Oct 28, 2022 at 04:22:54PM -0500, Eric DeVolder wrote: > /* > * For the kexec_file_load() syscall path, specify the maximum number of > * memory regions that the elfcorehdr buffer/segment can accommodate. > * These regions are obtained via walk_system_ram_res(); eg. the > * 'System RAM' entries in /proc/iomem. > * This value is combined with NR_CPUS and multiplied by sizeof(Elf64_Phdr) NR_CPUS_DEFAULT > * to determine the final elfcorehdr memory buffer/segment size. > * The value 8192, for example, covers a (sparsely populated) 1TiB system > * consisting of 128MiB memblock size, while resulting in an elfcorehdr > * memory buffer/segment size under 1MiB. ... and it is a sane choice trying to accomodate both actual baremetal and VM configurations." Yeah, it's a good start. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On 10/28/22 15:30, Borislav Petkov wrote: On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote: config CRASH_MAX_MEMORY_RANGES depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG int default 8192 help For the kexec_file_load path, specify the maximum number of memory regions, eg. as represented by the 'System RAM' entries in /proc/iomem, that the elfcorehdr buffer/segment can accommodate. This value is combined with NR_CPUS and multiplied by Elf64_Phdr size to determine the final buffer size. No, do this: config CRASH_MEMORY_HOTPLUG_SUPPORT depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG help Help text explaining what this feature is this thing will simply get enabled when the user enables MEMORY_HOTPLUG and CRASH_DUMP. and then you do in the code: /* * A comment explaining how the 8192 value has been selected. */ #define CRASH_MAX_MEMORY_RANGES 8192 Thx. How is this comment? /* * For the kexec_file_load() syscall path, specify the maximum number of * memory regions that the elfcorehdr buffer/segment can accommodate. * These regions are obtained via walk_system_ram_res(); eg. the * 'System RAM' entries in /proc/iomem. * This value is combined with NR_CPUS and multiplied by sizeof(Elf64_Phdr) * to determine the final elfcorehdr memory buffer/segment size. * The value 8192, for example, covers a (sparsely populated) 1TiB system * consisting of 128MiB memblock size, while resulting in an elfcorehdr * memory buffer/segment size under 1MiB. */ #define CRASH_MAX_MEMORY_RANGES 8192 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On 10/28/22 15:30, Borislav Petkov wrote: On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote: config CRASH_MAX_MEMORY_RANGES depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG int default 8192 help For the kexec_file_load path, specify the maximum number of memory regions, eg. as represented by the 'System RAM' entries in /proc/iomem, that the elfcorehdr buffer/segment can accommodate. This value is combined with NR_CPUS and multiplied by Elf64_Phdr size to determine the final buffer size. No, do this: config CRASH_MEMORY_HOTPLUG_SUPPORT depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG help Help text explaining what this feature is this thing will simply get enabled when the user enables MEMORY_HOTPLUG and CRASH_DUMP. and then you do in the code: /* * A comment explaining how the 8192 value has been selected. */ #define CRASH_MAX_MEMORY_RANGES 8192 Thx. ok, will do! thanks! eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Fri, Oct 28, 2022 at 02:26:58PM -0500, Eric DeVolder wrote: > config CRASH_MAX_MEMORY_RANGES > depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG > int > default 8192 > help > For the kexec_file_load path, specify the maximum number of > memory regions, eg. as represented by the 'System RAM' entries > in /proc/iomem, that the elfcorehdr buffer/segment can accommodate. > This value is combined with NR_CPUS and multiplied by Elf64_Phdr > size to determine the final buffer size. No, do this: config CRASH_MEMORY_HOTPLUG_SUPPORT depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG help Help text explaining what this feature is this thing will simply get enabled when the user enables MEMORY_HOTPLUG and CRASH_DUMP. and then you do in the code: /* * A comment explaining how the 8192 value has been selected. */ #define CRASH_MAX_MEMORY_RANGES 8192 Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On 10/28/22 12:06, Borislav Petkov wrote: On Fri, Oct 28, 2022 at 10:29:45AM -0500, Eric DeVolder wrote: So it is with this in mind that I suggest we stay with the statically sized elfcorehdr buffer. If that can be agreed upon, then it is "just a matter" of picking a useful elfcorehdr size. Currently that size is derived from the NR_DEFAULT_CPUS and CRASH_MAX_MEMORY_RANGES. So, there is still the CRASH_MAX_MEMORY_RANGES knob to help a dial in size, should there be some issue with the default value/size. Let's see kbuf.memsz = (CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES) * sizeof(Elf64_Phdr); which, IINM, is (8192 + 32768) * 56 which is something like 2M. (CONFIG_NR_CPUS_DEFAULT = 8192 - this is because of MAXSMP which gets set on distro kernels) Now, since userspace kexec tools uses 2048 for max memory ranges, that size becomes smaller - around half a Mb. And since y'all wanna be on the safe side, you can quadruple it and have (8192 + 8192) * 56 which is still under a megabyte. And that's fine, I guess, on a big server. Excellent, I'll set CRASH_MAX_MEMORY_RANGES to 8192! That seems a quite fair trade off of elfcorehdr size vs system size (ie 1TiB w/ 128MiB memblock size). Or if there is desire to drop computing the size from NR_DEFAULT_CPUs and I think you should leave the dependency on the Kconfig size so that smaller machines which are configured this way, don't end up wasting unnecessary memory. Excellent, I'll leave the computation as NR_DEFAULT_CPUS + CRASH_MAX_MEMORY_RANGES. It is my intention to correct the CRASH_MAX_MEMORY_RANGES (if we keep it) as such: config CRASH_MAX_MEMORY_RANGES depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG Yes, but don't leave it to the user to decide what number to choose - choose a high enough number, explain why you've chosen this with a comment and that's it. I currently have the Kconfig item as: config CRASH_MAX_MEMORY_RANGES depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG int default 8192 help For the kexec_file_load path, specify the maximum number of memory regions, eg. as represented by the 'System RAM' entries in /proc/iomem, that the elfcorehdr buffer/segment can accommodate. This value is combined with NR_CPUS and multiplied by Elf64_Phdr size to determine the final buffer size. I'll work to provide information a better explanation as to the 8192 number. Thank you! eric Thx. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Fri, Oct 28, 2022 at 10:29:45AM -0500, Eric DeVolder wrote: > So it is with this in mind that I suggest we stay with the statically sized > elfcorehdr buffer. > > If that can be agreed upon, then it is "just a matter" of picking a useful > elfcorehdr size. Currently that size is derived from the NR_DEFAULT_CPUS and > CRASH_MAX_MEMORY_RANGES. So, there is still the CRASH_MAX_MEMORY_RANGES knob > to help a dial in size, should there be some issue with the default > value/size. Let's see kbuf.memsz = (CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES) * sizeof(Elf64_Phdr); which, IINM, is (8192 + 32768) * 56 which is something like 2M. (CONFIG_NR_CPUS_DEFAULT = 8192 - this is because of MAXSMP which gets set on distro kernels) Now, since userspace kexec tools uses 2048 for max memory ranges, that size becomes smaller - around half a Mb. And since y'all wanna be on the safe side, you can quadruple it and have (8192 + 8192) * 56 which is still under a megabyte. And that's fine, I guess, on a big server. > Or if there is desire to drop computing the size from NR_DEFAULT_CPUs and I think you should leave the dependency on the Kconfig size so that smaller machines which are configured this way, don't end up wasting unnecessary memory. > It is my intention to correct the CRASH_MAX_MEMORY_RANGES (if we keep it) as > such: > > config CRASH_MAX_MEMORY_RANGES > depends on CRASH_DUMP && KEXEC_FILE && MEMORY_HOTPLUG Yes, but don't leave it to the user to decide what number to choose - choose a high enough number, explain why you've chosen this with a comment and that's it. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On 10/28/22 05:19, Borislav Petkov wrote:
On Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote:
Be aware, in reality, that if the system was fully populated, it would not
actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a
large contiguous address space which would require just a single phdr.
Then that from below:
pnum += CONFIG_CRASH_MAX_MEMORY_RANGES;
which then would end up allocating 8192 would be a total waste.
So why don't you make that number dynamic then?
You start with something sensible:
total_num_pheaders = num_online_cpus() + "some number of regions" + "some
few others"
I.e., a number which is a good compromise on the majority of machines.
Then, on hotplug events you count how many new regions are coming in
and when you reach the total_num_pheaders number, you double it (or some
other increase stragegy), reallocate the ELF header buffers etc needed
for kdump and you're good.
This way, you don't waste memory unnecessarily on the majority of
systems and those who need more, get to allocate more.
This patch series sizes and allocates the memory buffer/segment for the elfcorehdr once, at kdump
load time.
In order to dynamically resize the elcorehdr memory buffer/segment, that causes the following ripple
effects:
- Permitting resizing of the elfcorehdr requires a means to "allocate" a new size buffer from
within the crash kernel reserved area. There is no allocator today; currently it is a kind of
one-pass placement process that happens at load time. The critical side effect of allocating a new
elfcorehdr buffer memory/segment is that it creates a new address for the elfcorehdr.
- The elfcorehdr is passed to the crash kernel via the elfcorehdr= kernel cmdline option. As such,
a dynamic change to the size of the elfcorehdr size necessarily invites a change of address of that
buffer, and therefore a change to rewrite the crash kernel cmdline to reflect the new elfcorehdr
buffer address.
- A change to the cmdline, also invites a possible change of address of the buffer containing the
cmdline, and thus a change to the x86 boot_params, which contains the cmdline pointer.
- A change to the cmdline and/or boot_params, which are *not* excluded from the hash/digest, means
that the purgatory hash/digest needs to be recomputed, and purgatory re-linked with the new
hash/digest and replaced.
A fair amount of work, but I have had this working in the past, around the v1 patch series
timeframe. However, it only worked for the kexec_file_load() syscall as all the needed pieces of
information were available; but for kexec_load(), it isn't possible to relink purgatory as by that
point purgatory is but a user-space binary blob.
It was feedback on the v1/v2 that pointed out that by excluding the elfcorehdr from the hash/digest,
the "change of address" problem with the elfcorehdr buffer/segment goes away, and, in turn, negates
the need to: introduce an allocator for the crash kernel reserved space, rewrite the crash kernel
cmdline with a new elfcorehdr, update boot_params with a new cmdline and re-link and replace
purgatory with the updated digest. And it enables this hotplug efforts to support kexec_load()
syscall as well.
So it is with this in mind that I suggest we stay with the statically sized
elfcorehdr buffer.
If that can be agreed upon, then it is "just a matter" of picking a useful elfcorehdr size.
Currently that size is derived from the NR_DEFAULT_CPUS and CRASH_MAX_MEMORY_RANGES. So, there is
still the CRASH_MAX_MEMORY_RANGES knob to help a dial in size, should there be some issue with the
default value/size.
Or if there is desire to drop computing the size from NR_DEFAULT_CPUs and CRASH_MAX_MEMORY_RANGES
and simply go with CRASH_HOTPLUG_ELFCOREHDR_SZ which simply specifies the buffer size, then I'm also
good with that.
I still owe a much better explanation of how to size the elfcorehdr. I can use the comments and
ideas from the discussion to provide the necessary insight when choosing this value, whether that be
CRASH_MAX_MEMORY_RANGES or CRASH_HOTPLUG_ELFCOREHDR_SZ.
I'd prefer keeping CRASH_MAX_MEMORY_RANGES as that allow the maximum phdr
number value to be reflective of CPUs and/or memory; not all systems support
both CPU and memory hotplug. For example, I have queued up this change to
reflect this:
if (IS_ENABLED(CONFIG_HOTPLUG_CPU) || IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) {
If you're going to keep CRASH_MAX_MEMORY_RANGES, then you can test only
that thing as it expresses the dependency on CONFIG_HOTPLUG_CPU and
CONFIG_MEMORY_HOTPLUG already.
If you end up making the number dynamic, then you could make that a
different Kconfig item which contains all that crash code as most of the
people won't need it anyway.
It is my intention to correct the CRASH_MAX_MEMORY_RANGES (if we keep it) as
such:
config CRASH_MAX_MEMORY_RANGES
depends on CRASH_DUMP && KEXEC_FILE &&
Bug: kexec on Lenovo ThinkPad T480 disables EFI mode
Greetings, I've been hitting a bug on my Lenovo ThinkPad T480 where kexecing will cause EFI mode (if that's the right term for it) to be unconditionally disabled, even when not using the --noefi option to kexec. What I mean by "EFI mode" being disabled, more than just EFI runtime services, is that basically nothing about the system's EFI is visible post-kexec. Normally you have a message like this in dmesg when the system is booted in EFI mode: [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x7f98a000 ACPI=0x7fb7e000 ACPI 2.0=0x7fb7e014 MEMATTR=0x7ec63018 (obviously not the real firmware of the machine I'm talking about, but I can also send that if it would be of any help) No such message pops up in my dmesg as a result of this bug, & this causes some fallout like being unable to find the system's DMI information: <6>[0.00] DMI not present or invalid. The efivarfs module also fails to load with -ENODEV. I've tried also booting with efi=runtime explicitly but it doesn't change anything. The kernel still does not print the name of the EFI firmware, DMI is still missing, & efivarfs still fails to load. I've been using the kexec_load syscall for all these tests, if it's important. Also, to make it very clear, all this only ever happens post-kexec. When booting straight from UEFI (with the EFI stub), all the aforementioned stuff that fails works perfectly fine (i.e. name of firmware is printed, DMI is properly found, & efivarfs loads & mounts just fine). This is reproducible with a vanilla 6.1-rc2 kernel. I've been trying to bisect it, but it seems like it goes pretty far back. I've got vanilla mainline kernel builds dating back to 5.17 that have the exact same issue. It might be worth noting that during this testing, I made sure the version of the kernel being kexeced & the kernel kexecing were the same version. It may not have been a problem in older kernels, but that would be difficult to test for me (a pretty important driver for this machine was only merged during v5.17-rc4). So it may not have been a regression & just a hidden problem since time immemorial. I am willing to test any patches I may get to further debug or fix this issue, preferably based on the current state of torvalds/linux.git. I can build & test kernels quite a few times per day. I can also send any important materials (kernel config, dmesg, firmware information, so on & so forth) on request. I'll also just mention I'm using kexec-tools 2.0.24 upfront, if it matters. Regards, ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
On Wed, Oct 26, 2022 at 10:13:48AM +0800, Xianting Tian wrote:
> Hi Simon
>
> thanks for the comments
>
> 在 2022/10/21 下午11:27, Simon Horman 写道:
> > On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
> > > From: Nick Kossifidis
> > >
> > > This patch adds support for loading the ELF kernel image. It parses
> > > the current/provided device tree to determine the system's memory
> > > layout, and /proc/iomem for the various kernel segments.
> > >
> > > This patch was firstly developed by Nick Kossifidis, and two fixes (
> > > 1: fail to find free memory area for dtb load when using initrd image,
> > >lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
> > > 2: fix memory range size calculation,
> > > kexec/arch/riscv/crashdump-riscv.c:line 85
> > > ) are contributed by Yixun Lan, Xianting Tian.
> > >
> > > Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie 910
> > > CPU.
> > Hi,
> >
> > thanks for some patch.
> >
> > Some minor feedback follows.
> >
> > Separately, I'll post a patch to add RISC-V builds to the github
> > workflow. If you could include that in V3 I'd be most grateful.
> >
> > > Tested-by: Yixun Lan
> > > Co-developed-by: Xianting Tian
> > > Co-developed-by: Yixun Lan
> > > Signed-off-by: Nick Kossifidis
> > ...
> >
> > > + ret = mem_regions_alloc_and_add(mem_ranges, start,
> > > + end - start, type);
> > mem_regions_alloc_and_add isn't always available.
> > f.e. on mips this causes a build failure.
> >
> > Ref:
> > https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
>
> As you know, mem_regions_sort, mem_regions_alloc_and_add are the common
> funtions,
>
> The build error of mips is caused by this riscv patch?
Yes, I think so.
The workflow passes on main:
https://github.com/horms/kexec-tools/actions/runs/3344523519
But not with the riscv patch applied:
https://github.com/horms/kexec-tools/tree/build-test-riscv-v2
> kexec/mem_regions.c:void mem_regions_sort(struct memory_ranges *ranges)
> kexec/mem_regions.h:void mem_regions_sort(struct memory_ranges *ranges);
>
>
> kexec/mem_regions.c:int mem_regions_alloc_and_add(struct memory_ranges
> *ranges,
> kexec/mem_regions.h:int mem_regions_alloc_and_add(struct memory_ranges
> *ranges,
>
> >
> > ...
> >
> > > +int dtb_get_memory_ranges(char *dtb, struct memory_ranges *mem_ranges,
> > > struct memory_ranges *extra_ranges)
> > > +{
> > ...
> >
> > > + mem_regions_sort(mem_ranges);
> > Likewise, mem_regions_sort isn't always available.
> > f.e. on mips this causes a build failure.
> >
> > ...
> >
> > > diff --git a/purgatory/arch/riscv/Makefile b/purgatory/arch/riscv/Makefile
> > > new file mode 100644
> > > index 000..8bded71
> > > --- /dev/null
> > > +++ b/purgatory/arch/riscv/Makefile
> > > @@ -0,0 +1,7 @@
> > > +#
> > > +# Purgatory riscv
> > > +#
> > > +
> > > +riscv_PURGATORY_SRCS =
> > > +
> > > +dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
> > s/sh/riscv/
> >
> > Else the distribution tarball won't include this Makefile
> >
> > You can exercise this using:
> >make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
> thanks, I will fix this.
Thanks.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote:
> Be aware, in reality, that if the system was fully populated, it would not
> actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a
> large contiguous address space which would require just a single phdr.
Then that from below:
pnum += CONFIG_CRASH_MAX_MEMORY_RANGES;
which then would end up allocating 8192 would be a total waste.
So why don't you make that number dynamic then?
You start with something sensible:
total_num_pheaders = num_online_cpus() + "some number of regions" +
"some few others"
I.e., a number which is a good compromise on the majority of machines.
Then, on hotplug events you count how many new regions are coming in
and when you reach the total_num_pheaders number, you double it (or some
other increase stragegy), reallocate the ELF header buffers etc needed
for kdump and you're good.
This way, you don't waste memory unnecessarily on the majority of
systems and those who need more, get to allocate more.
> I'd prefer keeping CRASH_MAX_MEMORY_RANGES as that allow the maximum phdr
> number value to be reflective of CPUs and/or memory; not all systems support
> both CPU and memory hotplug. For example, I have queued up this change to
> reflect this:
>
> if (IS_ENABLED(CONFIG_HOTPLUG_CPU) || IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) {
If you're going to keep CRASH_MAX_MEMORY_RANGES, then you can test only
that thing as it expresses the dependency on CONFIG_HOTPLUG_CPU and
CONFIG_MEMORY_HOTPLUG already.
If you end up making the number dynamic, then you could make that a
different Kconfig item which contains all that crash code as most of the
people won't need it anyway.
Hmm?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] workflow: update to checkout@v3
On Fri, Oct 21, 2022 at 05:27:57PM +0200, Simon Horman wrote: > Use to checkout@v3 instead of checkout@v2 > as the latter uses Node.js 12 actions which are deprecated. > > https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/ > > Signed-off-by: Simon Horman Applied ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
