Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory

[Gupta, Pankaj]

> > The memory accounting in Linux is probably the issue. Both times I ran
> > the test were from a freshly booted VM. The test parses the output of
> > $(free -k) to determine the amount of free memory it should allocate
> > and write/read from, with a given stride of pages to skip before
> > touching the next page.
> >
> > We grab the third column of numbers from the Mem output that looks like this
> >
> >                 total        used        free      shared  buff/cache   available
> > Mem:        65856604     4128688    48558952       11208    13168964    60942928
> > Swap:        1953788      118124     1835664
> >
> > So my workstation has 48558952 free bytes. We take that, give it to
> > memtouch to allocate that much anonymous memory rounded down to the
> > nearest MB with mmap and randomly read/write the buffer.
> >
> > For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and
> > 0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The
> > next 5GB is classified as the UEFI v2.9 memory type
> > EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000.
> > The Linux e820 map should see that range as unaccepted rather than
> > EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but
> > I think it needs to be accounted as free conventional memory.
> >
> > So when I see 2044MB free vs 7089MB free in my VMs, the two are
> > roughly 5GB different.
>
> Please see/read/use
...

Apologies, some problem in my email client (appending long characters to 
links), will find and correct.

Thank you for pointing.

Best regards,
Pankaj