lkml.org 
[lkml]   [2020]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 6/6] mm/gup: migrate pinned pages out of movable zone
    > It is a good moment to say, I really dislike how this was implemented
    > in the first place.
    >
    > Scanning the output of gup just to do the is_migrate_movable() test is
    > kind of nonsense and slow. It would be better/faster to handle this
    > directly while gup is scanning the page tables and adding pages to the
    > list.

    Hi Jason,

    I assume you mean to migrate pages as soon as they are followed and
    skip those that are faulted, as we already know that faulted pages are
    allocated from nomovable zone.

    The place would be:

    __get_user_pages()
    while(more pages)
    get_gate_page()
    follow_hugetlb_page()
    follow_page_mask()

    if (!page)
    faultin_page()

    if (page && !faulted && (gup_flags & FOLL_LONGTERM) )
    check_and_migrate this page

    I looked at that function, and I do not think the code will be cleaner
    there, as that function already has a complicated loop. The only
    drawback with the current approach that I see is that
    check_and_migrate_movable_pages() has to check once the faulted pages.
    This is while not optimal is not horrible. The FOLL_LONGTERM should
    not happen too frequently, so having one extra nr_pages loop should
    not hurt the performance. Also, I checked and most of the users of
    FOLL_LONGTERM pin only one page at a time. Which means the extra loop
    is only to check a single page.

    We could discuss improving this code farther. For example, I still
    think it would be a good idea to pass an appropriate gfp_mask via
    fault_flags from gup_flags instead of using
    PF_MEMALLOC_NOMOVABLE (previously PF_MEMALLOC_NOCMA) per context flag.
    However, those changes can come after this series. The current series
    fixes a bug where hot-remove is not working with making minimal amount
    of changes, so it is easy to backport it to stable kernels.

    Thank you,
    Pasha



    >
    > Now that this becoming more general, can you take a moment to see if a
    > better implementation could be possible?
    >
    > Also, something takes care of the gup fast path too?
    >
    > Jason

    \
     
     \ /
      Last update: 2020-12-03 01:22    [W:4.745 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site