Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

[Yeoreum Yun <yeoreum.yun@arm.com>]

Hi Yang,
>
>
> On 1/20/26 3:01 PM, Yeoreum Yun wrote:
> > Hi Yang,
> > >
> > > On 1/20/26 1:29 AM, Yeoreum Yun wrote:
> > > > Hi Ryan
> > > > > On 19/01/2026 21:24, Yeoreum Yun wrote:
> > > > > > Hi Will,
> > > > > >
> > > > > > > On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:
> > > > > > > > +static int __init linear_map_prealloc_split_pgtables(void)
> > > > > > > > +{
> > > > > > > > +	int ret, i;
> > > > > > > > +	unsigned long lstart = _PAGE_OFFSET(vabits_actual);
> > > > > > > > +	unsigned long lend = PAGE_END;
> > > > > > > > +	unsigned long kstart = (unsigned long)lm_alias(_stext);
> > > > > > > > +	unsigned long kend = (unsigned long)lm_alias(__init_begin);
> > > > > > > > +
> > > > > > > > +	const struct mm_walk_ops collect_to_split_ops = {
> > > > > > > > +		.pud_entry	= collect_to_split_pud_entry,
> > > > > > > > +		.pmd_entry	= collect_to_split_pmd_entry
> > > > > > > > +	};
> > > > > > > Why do we need to rewalk the page-table here instead of collating the
> > > > > > > number of block mappings we put down when creating the linear map in
> > > > > > > the first place?
> > > > > That's a good point; perhaps we can reuse the counters that this series introduces?
> > > > >
> > > > > https://lore.kernel.org/all/20260107002944.2940963-1-yang@os.amperecomputing.com/
> > > Yeah, good point. It seems feasible to me. The patch can count how many
> > > PUD/CONT_PMD/PMD mappings, we can calculate how many page table pages need
> > > to be allocated based on those counters.
> > >
> > > > > > First, linear alias of the [_text, __init_begin) is not a target for
> > > > > > the split and it also seems strange to me to add code inside alloc_init_XXX()
> > > > > > that both checks an address range and counts to get the number of block mappings.
> > > IIUC, it should be not that hard to exclude kernel mappings. We know
> > > kernel_start and kernel_end, so you should be able to maintain a set of
> > > counters for kernel, then minus them when you do the calculation for how
> > > many page table pages need to be allocated.
> > As you said, this is not difficult. However, what I meant was that
> > this collection would be done in alloc_init_XXX(), and in that case,
> > collecting the number of block mappings for the range
> > [kernel_start, kernel_end) and adding conditional logic in
> > alloc_init_XXX() seems a bit odd.
> > That said, for potential future use cases involving splitting specific ranges,
> > I don’t think having this kind of collection is necessarily a bad idea.
>
> I'm not sure whether we are on the same page or not. IIUC the point is
> collecting the counts of PUD/CONT_PMD/PMD by re-walking page table is sub
> optimal and unnecessary for this usecase (repainting linear mapping). We can
> simply know the counts at linear mapping creation time.

What I meant was that the counts collected via dm_meminfo already
include kernel aliases, so adding separate code to
count kernel aliases again seems odd to me.
That said, I do not disagree with the efficiency of
using the already collected counts.

Thanks!

[...]

--
Sincerely,
Yeoreum Yun