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? > On baremetal system, basically only very high end server support > memory hotplug. I ever visited customer's lab and saw one server, > it owns 8 slots, on each slot a box containing about 20 cpus and 2T > memory at most can be plugged in at one time. So people won't make too > many slots for hotplugging since it's too expensive. There you have it - the persuading argument. > I checked user space kexec code, the maximum memory range number is > honored to x86_64 because of a HPE SGI system. After that, nobody > complains about it. Please see below user space kexec-tools commit in > https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git > > The memory ranges may be not all made by different DIMM slots, could be > firmware reservatoin, e.g efi/BIOS diggged out physical memory, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I don't know what that means. If it is firmware crap, you want to exclude that from kdump anyway. > Now CONFIG_NR_CPUS has the maximum number as 8192. And user space > kexec-tools has maximum memory range number as 2048. We can take > the current 8192 + 2048 = 10K as default value conservatively. Or > take 8192 + 2048 * 2 = 12K which has two times of maximum memory range > bumber in kexec-tools. What do you think? I still think that we should stick to reality and support what is possible not what is potentially and theoretically there. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
