Hi, Mike, On Tue, Mar 8, 2022 at 1:37 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > Hi, > > On Fri, Mar 04, 2022 at 08:43:03PM +0800, Huacai Chen wrote: > > Hi, Mike, > > > > On Fri, Mar 4, 2022 at 6:49 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > > > > So ideally, the physical memory detection and registration should follow > > > something like: > > > > > > * memblock_reserve() the memory used by firmware, kernel and initrd > > > * detect NUMA topology > > > * add memory regions along with their node ids to memblock. > > > > > > s390::setup_arch() is a good example of doing early reservations: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/setup.c#n988 > > I have a fast reading of S390, and I think we can do some adjust: > > 1, call memblock_set_node(0, ULONG_MAX, &memblock.memory, 0) in > > early_memblock_init(). > > 2, move memblock_reserve(PHYS_OFFSET, 0x200000) and > > memblock_reserve(__pa_symbol(&_text), __pa_symbol(&_end) - > > __pa_symbol(&_text)) to early_memblock_init(). > > 3, Reserve initrd memory in the first place. > > It is nearly the same as the S390, then. > > It does not have to look like the same as s390 :) > The important thing is to reserve all the memory before memblock > allocations are possible. New version is here, it's not completely the same as S390, but very similar: https://lore.kernel.org/linux-arch/20220306112850.811504-1-chenhuacai@xxxxxxxxxxx/T/#Z2e.:..:20220306112850.811504-10-chenhuacai::40loongson.cn:1arch:loongarch:kernel:mem.c Firmware is not in SYSRAM regions, so we don't need to reserve them. The first 2MB and the kernel region are reserved in early_memblock_init(), before any allocations. Initrd information is passed by cmdline, and initrd is now reserved immediately after cmdline has parsed, by merging init_initrd/finalize_initrd as you suggested: https://lore.kernel.org/linux-arch/20220306112850.811504-1-chenhuacai@xxxxxxxxxxx/T/#Z2e.:..:20220306112850.811504-10-chenhuacai::40loongson.cn:1arch:loongarch:kernel:setup.c > > > > > > > +early_param("memmap", early_parse_memmap); > > > > > > > > > > The memmap= processing is a hack indented to workaround bugs in firmware > > > > > related to the memory detection. Please don't copy if over unless there is > > > > > really strong reason. > > > > > > > > Hmmm, I have read the documents, most archs only support mem=limit, > > > > but MIPS support mem=limit@base. memmap not only supports > > > > memmap=limit@base, but also a lot of advanced syntax. LoongArch needs > > > > both limit and limit@base syntax. So can we make our code to support > > > > only mem=limit and memmap=limit@base, and remove all other syntax > > > > here? > > > > > > The documentation describes what was there historically and both these > > > options tend not to play well with complex memory layouts. > > > > > > If you must have them it's better to use x86 as an example rather than > > > MIPS, just take into the account that on x86 memory always starts from 0, > > > so they never needed to have a different base. > > > > > > For what use-cases LoongArch needs options? > > > > The use-case of limit@base syntax is kdump, because our kernel is not > > relocatable. I'll use X86 as an example. > > I missed that mem= can be used several times, so with MIPS implementation > it's possible to define something like "mem=limit0@base0 mem=limit1@base1" > and this will create two contiguous memory regions. The new version is here: https://lore.kernel.org/linux-arch/20220306112850.811504-1-chenhuacai@xxxxxxxxxxx/T/#Z2e.:..:20220306112850.811504-10-chenhuacai::40loongson.cn:1arch:loongarch:kernel:setup.c If I use the MIPS implementation, then memmap= is useless and can be removed, but the MIPS implementation is not obey the rules in kernel documents. Huacai > > > Huacai > > -- > Sincerely yours, > Mike.
