Hi, While preparing v5, I retested the LoongArch vmtest without the explicit `kho_scratch=16M,16M,16M` setting. That setting was masking a pre-existing bug in the generic percentage-based KHO scratch sizing.
The percentage heuristic itself is reasonable, but the old implementation calculated each per-node baseline after allocating the lowmem and global scratch areas. Since memblock allocations are marked MEMBLOCK_RSRV_KERN, those scratch areas were counted as new kernel demand and scaled again. On the 1 GiB LoongArch guest, the 98.45 MiB reservation baseline and 32 MiB alignment made the old ordering request 224 MiB of lowmem scratch followed by 672 MiB for node 0. The node allocation failed and disabled KHO. I sent a separate generic fix here: https://lore.kernel.org/loongarch/[email protected] With that fix, the total aligned request is 448 MiB and the LoongArch vmtest passes using the default percentage-based sizing. I also ran the x86 KHO vmtest with the fix; it passes as well. Therefore, I will remove `kho_scratch=16M,16M,16M` from loongarch.conf in v5 so that it tests the default sizing path, matching the existing x86 selftest behavior. Thanks, George
