Re: [PATCH v4 4/4] selftests/kho: add LoongArch vmtest support

[Pratyush Yadav <pratyush@kernel.org>]

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/20260904025101.9959-1-dongtai.guo@linux.dev

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/20260821105609.983622-1-sourabhjain@linux.ibm.com/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