Split page tables
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
Hi Bahadir,
(good to see you around :-))
Quoted 6 lines · Bahadir Balban
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_SIZEto become smaller? Whatif it was made0x80000000?
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.
Signature · 1 line
Catalin
Quoted 4 lines · Catalin Marinas
Hi Bahadir,
(good to see you around :-))
Good to see you too, Catalin.
Quoted 9 lines
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
Quoted 10 lines · Bahadir Balban
Quoted 8 lines · Catalin Marinas
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 1 line
Catalin