Split page tables

Split page tables

[Bahadir Balban]

Hello,

If split page tables were used in v6/v7, there might have been 
significant page table area savings e.g. 8KB * 256 = 2MB on a 256 
address space system with a 2GB task address space. This also seems to 
bring the relief of not having to map global mappings to every page 
table at run-time. Why wasn't this route chosen? Perhaps because it 
needs the TASK_SIZE to become smaller? Whatif it was made 0x8000 0000?

Thanks,

Bahadir

Split page tables

[Catalin Marinas]

Hi Bahadir,

(good to see you around :-))

On Mon, 2010-01-11 at 19:59 +0000, Bahadir Balban wrote:
> If split page tables were used in v6/v7, there might have been
> significant page table area savings e.g. 8KB * 256 = 2MB on a 256
> address space system with a 2GB task address space. This also seems to
> bring the relief of not having to map global mappings to every page
> table at run-time. Why wasn't this route chosen? Perhaps because it
> needs the TASK_SIZE to become smaller? Whatif it was made 0x8000 0000?

You can configure a 2:2 split and if you want you can set TTBR1 to the
kernel TTBR but I don't think you'd gain much. You only save about 2K of
the user TTBR but since we allocate a 1 x 4K page pgd, there isn't any
difference. Note the translation table entries for the kernel would
contain either level 1 section entries or entries pointing to level 2
tables which would be shared between all the pgd tables. I think the
only gain is probably a memcpy of the kernel pgd into the user pgd
during process creation.

-- 
Catalin

Split page tables

[Bahadir Balban]

Catalin Marinas wrote:
> Hi Bahadir,
> 
> (good to see you around :-))
> 

Good to see you too, Catalin.

> You can configure a 2:2 split and if you want you can set TTBR1 to the
> kernel TTBR but I don't think you'd gain much. You only save about 2K of
> the user TTBR but since we allocate a 1 x 4K page pgd, there isn't any
> difference. Note the translation table entries for the kernel would
> contain either level 1 section entries or entries pointing to level 2
> tables which would be shared between all the pgd tables. I think the
> only gain is probably a memcpy of the kernel pgd into the user pgd
> during process creation.
> 

I understand that level 2 tables are already shared on global mappings.
After taking a glance in pgtable.h, I see that there are 8-byte pgd 
entries and extra linux tables to make it fit for linux requirements. 
But still, it seems like instead of 16KB level1 tables per-space, a 2:2 
split would need 8KB level1 table per space which results in 8KB savings 
per-space. Am I missing something?

That said, with linux pte duplicates on every 2nd level table, it might 
not be a significant gain. Perhaps you had done the correlation long ago 
- but extra bits from tex remap and access flag is not enough to support 
linux bits directly on the hardware pte?


Thanks,

--
Bahadir

Split page tables

[Catalin Marinas]

On Tue, 2010-01-12 at 19:15 +0000, Bahadir Balban wrote:
> Catalin Marinas wrote:
> > You can configure a 2:2 split and if you want you can set TTBR1 to the
> > kernel TTBR but I don't think you'd gain much. You only save about 2K of
> > the user TTBR but since we allocate a 1 x 4K page pgd, there isn't any
> > difference. Note the translation table entries for the kernel would
> > contain either level 1 section entries or entries pointing to level 2
> > tables which would be shared between all the pgd tables. I think the
> > only gain is probably a memcpy of the kernel pgd into the user pgd
> > during process creation.
> 
> I understand that level 2 tables are already shared on global mappings.
> After taking a glance in pgtable.h, I see that there are 8-byte pgd
> entries and extra linux tables to make it fit for linux requirements.
> But still, it seems like instead of 16KB level1 tables per-space, a 2:2
> split would need 8KB level1 table per space which results in 8KB savings
> per-space. Am I missing something?

No, my calculations were wrong - you save 0x2000 which is 8KB indeed.

> That said, with linux pte duplicates on every 2nd level table, it might
> not be a significant gain. 

I think traditionally we had a 3:1 split for user:kernel which wasn't
suited for a TTBR split. The 2:2 split came as a requirement as more RAM
became available, so the 8KB save probably wasn't noticeable.

> Perhaps you had done the correlation long ago
> - but extra bits from tex remap and access flag is not enough to support
> linux bits directly on the hardware pte?

Yes, they are, and I already posted a patch:

http://thread.gmane.org/gmane.linux.ports.arm.kernel/70340/focus=70345

but the thread seems to have died.

-- 
Catalin