Hi-- On 6/1/22 09:20, Dionna Amalie Glaze wrote: > 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 https://people.kernel.org/tglx/notes-about-netiquette -- ~Randy
