On Fri, Sep 04 2026, George Guo wrote: > 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]
Oh, cool! Nice find. I just wrote Sourabh (+Cc) an email [0] about this too. I think there is other wonky stuff going on with scratch sizing, like global scratch being inflated. See my email [0] about that. Let me go review that patch, since this seems to be causing a lot of pain. [0] https://lore.kernel.org/kexec/[email protected]/T/#t > > 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 -- Regards, Pratyush Yadav
