lkml.org 
[lkml]   [2020]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 3/6] mm: support THP migration to device private memory
    On Fri, Nov 20, 2020 at 04:01:33PM -0400, Jason Gunthorpe wrote:
    > On Wed, Nov 11, 2020 at 03:38:42PM -0800, Ralph Campbell wrote:
    >
    > > MEMORY_DEVICE_GENERIC:
    > > Struct pages are created in dev_dax_probe() and represent non-volatile memory.
    > > The device can be mmap()'ed which calls dax_mmap() which sets
    > > vma->vm_flags | VM_HUGEPAGE.
    > > A CPU page fault will result in a PTE, PMD, or PUD sized page
    > > (but not compound) to be inserted by vmf_insert_mixed() which will call either
    > > insert_pfn() or insert_page().
    > > Neither insert_pfn() nor insert_page() increments the page reference
    > > count.
    >
    > But why was this done? It seems very strange to put a pfn with a
    > struct page into a VMA and then deliberately not take the refcount for
    > the duration of that pfn being in the VMA?
    >
    > What prevents memunmap_pages() from progressing while VMAs still point
    > at the memory?

    Agreed. Adding Roger who added MEMORY_DEVICE_GENERIC and the only
    user.

    > > I think just leaving the page reference count at one is better than trying
    > > to use the mmu_interval_notifier or changing vmf_insert_mixed() and
    > > invalidations of pfn_t_devmap(pfn) to adjust the page reference count.
    >
    > Why so? The entire point of getting struct page's for this stuff was
    > to be able to follow the struct page flow. I never did learn a reason
    > why there is devmap stuff all over the place in the page table code...

    Exactly.

    \
     
     \ /
      Last update: 2020-12-02 11:11    [W:4.933 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site