Re: [LSF/MM/BPF TOPIC] Per-process page size

[Dev Jain <dev.jain@arm.com>]

>>
>> 3. Translation from Linux pagetable to native pagetable
>> -------------------------------------------------------
>> Assume the case of a kernel pagesize of 4K and app pagesize of 64K.
>> Now that enlightenment is done, it is guaranteed that every single mapping
>> in the 4K pagetable (which we call the Linux pagetable) is of granularity
>> at least 64K. In the arm64 MM code, we maintain a "native" pagetable per
>> mm_struct, which is based off a 64K geometry. Because of the guarantee
>> aforementioned, any pagetable operation on the Linux pagetable
>> (set_ptes, clear_flush_ptes, modify_prot_start_ptes, etc) is going to happen
>> at a granularity of at least 16 PTEs - therefore we can translate this
>> operation to modify a single PTE entry in the native pagetable.
>> Given that enlightenment may miss corner cases, we insert a warning in the
>> architecture code - on being presented with an operation not translatable
>> into a native operation, we fallback to the Linux pagetable, thus losing
>> the benefits borne out of the pagetable geometry but keeping
>> the emulation intact.
> I don't understand. What exactly are you trying to do here? Maintain 2
> different paging structures, one for core mm and the other for the arch? As
> done in architectures with no radix tree paging structures?

The mm->pgd will be the software pagetable. So suppose that do_anonymous_page is
doing set_ptes on the PTE table belonging to the software pagetable. We will
hook a "native_set_ptes" into set_ptes, which will set the ptes on a different
pagetable maintained by arm64 code (probably mm_context_t->native_pgd).

>
> If so, that's wildly inefficient, unless you're willing to go into reclaimable
> page tables on the arm64 side. And that brings extra problems and extra fun :)

I didn't understand the reclaimable reference, but yes we need to make this efficient.
So for the above example I gave, native_set_ptes knows the virtual address to set -
walking the native hierarchy from native_pgd->native_pmd->native_pte (in case of 64K native
geometry) is inefficient. So we need to maintain a lookup mechanism from a linux pgtable
pointer to the native pgtable pointer.
The idea we have currently is to store such lookup in the struct ptdesc of the pagetable page.
For 4K Linux pagetable and 64K native pagetable, 512M/2M = 256 Linux PTE tables correspond
to different sections of the native PTE table. We will maintain the pointer to the relevant
section in the native PTE table, in the struct ptdesc of the pagetable page of the Linux
PTE table.
The other case is that a single Linux pgtable leaf entry corresponds to multiple native
leaf entries - take the case of a Linux PMD table which maps 1G of memory, this corresponds
to 2 native PTE tables (2 x 512M). We will have to store a list of pointers here.

>