On Fri 06-10-17 11:25:16, Pasha Tatashin wrote:

Hi Michal,

quoted

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