Hi Yang,

On 1/20/26 3:01 PM, Yeoreum Yun wrote:

quoted

Hi Yang,

quoted

On 1/20/26 1:29 AM, Yeoreum Yun wrote:

quoted

Hi Ryan

quoted

On 19/01/2026 21:24, Yeoreum Yun wrote:

quoted

Hi Will,

quoted

On Mon, Jan 05, 2026 at 08:23:27PM +0000, Yeoreum Yun wrote:

quoted

+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/ (local)

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.

quoted

quoted

quoted

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