• J
    mm/migrate: new migrate mode MIGRATE_SYNC_NO_COPY · 2916ecc0
    Jérôme Glisse 提交于
    Introduce a new migration mode that allow to offload the copy to a device
    DMA engine.  This changes the workflow of migration and not all
    address_space migratepage callback can support this.
    
    This is intended to be use by migrate_vma() which itself is use for thing
    like HMM (see include/linux/hmm.h).
    
    No additional per-filesystem migratepage testing is needed.  I disables
    MIGRATE_SYNC_NO_COPY in all problematic migratepage() callback and i
    added comment in those to explain why (part of this patch).  The commit
    message is unclear it should say that any callback that wish to support
    this new mode need to be aware of the difference in the migration flow
    from other mode.
    
    Some of these callbacks do extra locking while copying (aio, zsmalloc,
    balloon, ...) and for DMA to be effective you want to copy multiple
    pages in one DMA operations.  But in the problematic case you can not
    easily hold the extra lock accross multiple call to this callback.
    
    Usual flow is:
    
    For each page {
     1 - lock page
     2 - call migratepage() callback
     3 - (extra locking in some migratepage() callback)
     4 - migrate page state (freeze refcount, update page cache, buffer
         head, ...)
     5 - copy page
     6 - (unlock any extra lock of migratepage() callback)
     7 - return from migratepage() callback
     8 - unlock page
    }
    
    The new mode MIGRATE_SYNC_NO_COPY:
     1 - lock multiple pages
    For each page {
     2 - call migratepage() callback
     3 - abort in all problematic migratepage() callback
     4 - migrate page state (freeze refcount, update page cache, buffer
         head, ...)
    } // finished all calls to migratepage() callback
     5 - DMA copy multiple pages
     6 - unlock all the pages
    
    To support MIGRATE_SYNC_NO_COPY in the problematic case we would need a
    new callback migratepages() (for instance) that deals with multiple
    pages in one transaction.
    
    Because the problematic cases are not important for current usage I did
    not wanted to complexify this patchset even more for no good reason.
    
    Link: http://lkml.kernel.org/r/20170817000548.32038-14-jglisse@redhat.comSigned-off-by: NJérôme Glisse <jglisse@redhat.com>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Balbir Singh <bsingharora@gmail.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: David Nellans <dnellans@nvidia.com>
    Cc: Evgeny Baskakov <ebaskakov@nvidia.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Mark Hairgrove <mhairgrove@nvidia.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sherry Cheung <SCheung@nvidia.com>
    Cc: Subhash Gutti <sgutti@nvidia.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Bob Liu <liubo95@huawei.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    2916ecc0
data.c 53.8 KB