Re: [PATCH 3/4] arm64: mm: support large block mapping when rodata=full

From: Yang Shi
Date: Wed Jul 23 2025 - 16:52:15 EST




On 7/23/25 10:38 AM, Dev Jain wrote:

On 23/06/25 6:56 pm, Ryan Roberts wrote:
[...]

+
+int split_leaf_mapping(unsigned long addr)
Thanks for coming up with the code. It does help to understand your idea. Now I
see why you suggested "split_mapping(start); split_mapping(end);" model. It does
make the implementation easier because we don't need a loop anymore. But this
may have a couple of problems:
   1. We need walk the page table twice instead of once. It sounds expensive.
Yes we need to walk twice. That may be more expensive or less expensive,
depending on the size of the range that you are splitting. If the range is large
then your approach loops through every leaf mapping between the start and end
which will be more expensive than just doing 2 walks. If the range is small then
your approach can avoid the second walk, but at the expense of all the extra
loop overhead.

My suggestion requires 5 loads (assuming the maximum of 5 levels of lookup).
Personally I think this is probably acceptable? Perhaps we need some other
voices here.

Hello all,

I am starting to implement vmalloc-huge by default with BBML2 no-abort on arm64.
I see that there is some disagreement related to the way the splitting needs to
be implemented - I skimmed through the discussions and it will require some work
to understand what is going on :) hopefully I'll be back soon to give some of
my opinions.

Hi Dev,

Thanks for the heads up.

In the last email I suggested skip the leaf mappings in the split range in order to reduce page table walk overhead for split_mapping(start, end). In this way we can achieve:
    - reuse the most split code for repainting (just need NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS flag for repainting to split page table to PTEs)
    - just walk page table once
    - have similar page table walk overhead with split_mapping(start)/split_mapping(end) if the split range is large

I'm basically done on a new spin to implement it and solve all the review comments from v4. I should be able to post the new spin by the end of this week.

Regards,
Yang