>> I am not sure I understand what you mean with "there is no guarantee as to >> where the first chunk of used memory lie above your rootfs memory". >> How is it different to when it was local?
>Earlier, with a local lmb map, one could define a map inside a function, with >available memory and used memory which could be controlled inside some >function. This is no longer possible. There could be an allocation that could >have happened above the rootfs memory, which would mean that the free memory >computation would be non-deterministic. So with a global and persistent lmb >memory map, this is no longer a robust way to compute memory available for the >kernel. Thanks, now I get it. I think for the moment we will keep it like this, since we are running this code as one of the last steps in the boot command (after this, we only tftp the rootfs itself and then boot) and it's not critical functionality. >As an aside, I am not sure if you have considered using the UEFI interfaces >for booting the kernel. The EFI firmware (U-Boot in this case) passes a memory map to the kernel which specifies which memory the kernel can use, and which is reserved. Booting the kernel with EFI interfaces, the memory occupied by the ramfs can then be marked as EfiReservedMemoryType, and this would not be used by the kernel. This definitely can be done on armv8 platforms -- I have not booted a kernel with EFI interfaces on armv7 boards though. Something to consider for your solution. This sounds like a better solution, absolutely, I'll look into it eventually. Thanks for your time and patience, this was helpful. Regarding the initial question, I think then that there isn't a case where you want to greedily check how much memory you can reserve starting at a particular address? Tomas
