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

[Yang Shi <yang@os.amperecomputing.com>]

On 7/24/25 4:43 AM, Dev Jain wrote:
>
> On 24/07/25 2:21 am, Yang Shi wrote:
>>
>>
>> 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.
>
> 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?

Yeah, sure. But I saw Andrew had some nits on the generic mm code part. 
The other way is you can have your patch applied on top of my series so 
that we don't interlock each other. Anyway I will still keep it as 
prerequisite of my series for now.

Yang

>
>
>>
>> Regards,
>> Yang
>>
>>>
>>>>
>>>>
>>