On Fri 06-10-17 11:25:16, Pasha Tatashin wrote: > Hi Michal, > > > > > As I've said in other reply this should go in only if the scenario you > > describe is real. I am somehow suspicious to be honest. I simply do not > > see how those weird struct pages would be in a valid pfn range of any > > zone. > > > > There are examples of both when unavailable memory is not part of any zone, > and where it is part of zones. > > I run Linux in kvm with these arguments: > > qemu-system-x86_64 > -enable-kvm > -cpu kvm64 > -kernel $kernel > -initrd $initrd > -m 512 > -smp 2 > -device e1000,netdev=net0 > -netdev user,id=net0 > -boot order=nc > -no-reboot > -watchdog i6300esb > -watchdog-action debug > -rtc base=localtime > -serial stdio > -display none > -monitor null > > This patch reports that there are 98 unavailable pages. > > They are: pfn 0 and pfns in range [159, 255]. > > Note, trim_low_memory_range() reserves only pfns in range [0, 15], it does > not reserve [159, 255] ones. > > e820__memblock_setup() reports linux that the following physical ranges are > available: > [1 , 158] > [256, 130783] > > Notice, that exactly unavailable pfns are missing! > > Now, lets check what we have in zone 0: [1, 131039] > > pfn 0, is not part of the zone, but pfns [1, 158], are. > > However, the bigger problem we have if we do not initialize these struct > pages is with memory hotplug. Because, that path operates at 2M boundaries > (section_nr). And checks if 2M range of pages is hot removable. It starts > with first pfn from zone, rounds it down to 2M boundary (sturct pages are > allocated at 2M boundaries when vmemmap is created), and and checks if that > section is hot removable. In this case start with pfn 1 and convert it down > to pfn 0. Hmm, this is really interesting! I thought each memblock is guaranteed to be section size aligned. But I suspect this is more of a wishful thinking. But now I see what is the problem. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
