Re: [RFC PATCH 0/2] Optimize S2 page splitting

[Marc Zyngier <maz@kernel.org>]

On Fri, 15 May 2026 20:59:01 +0100,
Leonardo Bras <leo.bras@arm.com> wrote:
> 
> While playing with dirty-bit tracking, I decided to take a look on how page
> splitting works. Found out all entries are walked, even though we can infer,
> for instance that:
> - If a level-3 entry is walked, it means the parent level-2 entry is split
> - If a split just succeeded in an table entry, it means all children nodes
>   are already split
> 
> So I tried to optimize it in a way that it does not break other users.
> 
> My main idea is to introduce positive return values that hint to the
> pagetable walking mechanism that either siblings or children can be 
> skipped. That should be contained to the visitor function, that returns
> zero if no error was detected.
> 
> Numbers on above optimization are promising:
> A 1GB VM, running on the model, splitting all at the beginning 
> (no manual protect):
> - Memory was already split (4k pages): 	-97.33% runtime (-172ms) - 20 runs
> - THP backed memory: 			-19.82% runtime (-153ms) - 10 runs
> - 1x1GB hugetlb memory:			-20.65% runtime (-150ms) - 10 runs
>

I haven't looked at the changes in details, but the methodology is
quite flawed. For a start, measuring anything on a software model
(QEMU or FVP) doesn't mean anything performance-wise. The trade-offs
are completely different from a HW implementation, and even the notion
of time is pretty inconsistent.

Please run this on actual HW. I'm sure your employer can give you
access to one of these mythical arm64 toys. Measure things from
userspace, not from the kernel, so that you have all the overheads.
Don't add console output, because that will make things far worse.

I'm sure you can hack one of the selftests for this purpose.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.