lkml.org 
[lkml]   [2020]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM
    On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter <daniel@ffwll.ch> wrote:
    >
    > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard <jhubbard@nvidia.com> wrote:
    > >
    > > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
    > > > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
    > > >>> /*
    > > >>> * If we can't determine whether or not a pte is special, then fail immediately
    > > >>> * for ptes. Note, we can still pin HugeTLB and THP as these are guaranteed not
    > > >>> * to be special.
    > > >>> *
    > > >>> * For a futex to be placed on a THP tail page, get_futex_key requires a
    > > >>> * get_user_pages_fast_only implementation that can pin pages. Thus it's still
    > > >>> * useful to have gup_huge_pmd even if we can't operate on ptes.
    > > >>> */
    > > >>
    > > >> We support hugepage faults in gpu drivers since recently, and I'm not
    > > >> seeing a pud_mkhugespecial anywhere. So not sure this works, but probably
    > > >> just me missing something again.
    > > >
    > > > It means ioremap can't create an IO page PUD, it has to be broken up.
    > > >
    > > > Does ioremap even create anything larger than PTEs?
    >
    > gpu drivers also tend to use vmf_insert_pfn* directly, so we can do
    > on-demand paging and move buffers around. From what I glanced for
    > lowest level we to the pte_mkspecial correctly (I think I convinced
    > myself that vm_insert_pfn does that), but for pud/pmd levels it seems
    > just yolo.

    So I dug around a bit more and ttm sets PFN_DEV | PFN_MAP to get past
    the various pft_t_devmap checks (see e.g. vmf_insert_pfn_pmd_prot()).
    x86-64 has ARCH_HAS_PTE_DEVMAP, and gup.c seems to handle these
    specially, but frankly I got totally lost in what this does.

    The comment above the pfn_t_devmap check makes me wonder whether doing
    this is correct or not.

    Also adding Thomas Hellstrom, who implemented the huge map support in ttm.
    -Daniel

    > remap_pfn_range seems to indeed split down to pte level always.
    >
    > > From my reading, yes. See ioremap_try_huge_pmd().
    >
    > The ioremap here shouldn't matter, since this is for kernel-internal
    > mappings. So that's all fine I think.
    > -Daniel
    > --
    > Daniel Vetter
    > Software Engineer, Intel Corporation
    > http://blog.ffwll.ch



    --
    Daniel Vetter
    Software Engineer, Intel Corporation
    http://blog.ffwll.ch

    \
     
     \ /
      Last update: 2020-11-06 11:29    [W:7.837 / U:0.808 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site