On 24/07/25 2:21 am, Yang Shi wrote:

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

quoted

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.

Great! As Catalin notes on my huge-perm change series, that series 
doesn't have any user so it does not make sense for that to go in 
without your

series - can you merge that series into your work for the new version?

Regards,
Yang

quoted

quoted