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

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

quoted

[...]

quoted

quoted

+
+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

quoted