Re: [External] Re: [PATCH v2 6/9] mm: free user PTE page table pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2021/8/19 PM3:01, David Hildenbrand wrote:

In this patch series, we add a pte_refcount field to the
struct page of page table to track how many users of PTE page
table. Similar to the mechanism of page refcount, the user of
PTE page table should hold a refcount to it before accessing.
The PTE page table page will be freed when the last refcount
is dropped.

While we access ->pte_refcount of a PTE page table, any of the
following ensures the pmd entry corresponding to the PTE page
table stability:

    - mmap_lock
    - anon_lock
    - i_mmap_lock
    - parallel threads are excluded by other means which
      can make ->pmd stable(e.g. gup case)

This patch does not support THP temporarily, it will be
supported in the next patch.

Can you clarify (and document here) who exactly takes a reference on the page table? Do I understand correctly that

a) each !pte_none() entry inside a page table take a reference to the page it's containted in.
b) each page table walker temporarily grabs a page table reference
c) The PMD tables the PTE is referenced in (->currently only ever a single one) does *not* take a reference.

Yes, both of the !pte_none() entry and the page table walker can be
regarded as users of the PTE page table, so they need to hold a
->pte_refcount during their life cycle. And the pte_refcount field
of struct page is only for PTE page table, so the PMD page tables does
*not* take a ->pte_refcount.


So if there are no PTE entries left and nobody walks the page tables, you can remove it? You should really extend the

Yes, if there are no PTE entries left and nobody walks the page tables,
which means there is no user, then we can remove it when we drop the
last ->pte_refcount.

description/documentation to make it clearer how exactly it's supposed to work
I'm sorry that there is no clear description of the usage of
pte_refcount, i will make a documentation to describe it.



It feels kind of strange to not introduce the CONFIG_FREE_USER_PTE Kconfig option in this patch. At least it took me a while to identify it in the previous patch.

The introduction of the CONFIG_FREE_USER_PTE and related APIs are all
place in the previous patch ([PATCH v2 5/9] mm: pte_refcount
infrastructure). And in this and next patch, we use these
infrastructures to free user PTE page table pages.


Maybe you should introduce the empty stubs and use them in a separate patch, and then have this patch just introduce CONFIG_FREE_USER_PTE along with the actual refcounting magic inside the !stub implementation.

Hmm, let me think about this suggestion.

Thanks,

Qi






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux