|
Size: 1193
Comment:
|
Size: 1255
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| '''What are the design internals behind zap_xxx_range() APIs?''' |
|
| Line 2: | Line 4: |
| On Sun, 30 Mar 2008 17:55:26 +0800 "Wu Yu" <vestige.lug@gmail.com> wrote: |
On Sun, 30 Mar 2008 17:55:26 +0800 "Wu Yu" < vestige.lug@gmail.com > wrote: |
| Line 7: | Line 8: |
| Line 8: | Line 10: |
| Line 10: | Line 13: |
| This is done so all architectures can use the same iterative functions, like unmap_page_range -> zap_pud_range -> zap_pmd_range -> zap_pte_range. |
This is done so all architectures can use the same iterative functions, like unmap_page_range -> zap_pud_range -> zap_pmd_range -> zap_pte_range. |
| Line 14: | Line 15: |
| > I don't quite understand the word "mapping". Does that mean there > is one entry in PGD for both PUD and PMD? |
> I don't quite understand the word "mapping". Does that mean there > is one entry in PGD for both PUD and PMD? |
| Line 17: | Line 17: |
| It means that the kernel pretends that the pgd entry points to a pud (with one entry), even though it really points to a page table. |
It means that the kernel pretends that the pgd entry points to a pud (with one entry), even though it really points to a page table. |
| Line 20: | Line 19: |
| By pretenting it points to itself unmap_page_range can call the next function down, zap_pud_range. |
By pretenting it points to itself unmap_page_range can call the next function down, zap_pud_range. |
| Line 23: | Line 21: |
| We do the same thing in zap_pud_range - it calls zap_pmd_range on the same pgd entry, except now it thinks it points to a pmd. |
We do the same thing in zap_pud_range - it calls zap_pmd_range on the same pgd entry, except now it thinks it points to a pmd. |
| Line 26: | Line 23: |
| Finally, zap_pmd_range interprets the entry and sees that it points to a page table. Zap_pmd_range invokes zap_pte_range and everything works as normal. |
Finally, zap_pmd_range interprets the entry and sees that it points to a page table. Zap_pmd_range invokes zap_pte_range and everything works as normal. |
| Line 30: | Line 25: |
| Because, on i386, we pretend that the PUD and PMD page tables only have 1 entry, the loop does not loop, but simply invokes the next function down once. |
Because, on i386, we pretend that the PUD and PMD page tables only have 1 entry, the loop does not loop, but simply invokes the next function down once. |
What are the design internals behind zap_xxx_range() APIs?
Rik van Riel to Wu, kernelnewbies
On Sun, 30 Mar 2008 17:55:26 +0800 "Wu Yu" < vestige.lug@gmail.com > wrote:
> Hi all,
> AFAIK, for IA-32 arch, two-level paging is sufficient. But the
> positions of PUD and PMD are kept.
This is done so all architectures can use the same iterative functions, like unmap_page_range -> zap_pud_range -> zap_pmd_range -> zap_pte_range.
> I don't quite understand the word "mapping". Does that mean there > is one entry in PGD for both PUD and PMD?
It means that the kernel pretends that the pgd entry points to a pud (with one entry), even though it really points to a page table.
By pretenting it points to itself unmap_page_range can call the next function down, zap_pud_range.
We do the same thing in zap_pud_range - it calls zap_pmd_range on the same pgd entry, except now it thinks it points to a pmd.
Finally, zap_pmd_range interprets the entry and sees that it points to a page table. Zap_pmd_range invokes zap_pte_range and everything works as normal.
Because, on i386, we pretend that the PUD and PMD page tables only have 1 entry, the loop does not loop, but simply invokes the next function down once.