• Alistair Popple's avatar
    mm: remove special swap entry functions · af5cdaf8
    Alistair Popple authored
    Patch series "Add support for SVM atomics in Nouveau", v11.
    
    Introduction
    ============
    
    Some devices have features such as atomic PTE bits that can be used to
    implement atomic access to system memory.  To support atomic operations to
    a shared virtual memory page such a device needs access to that page which
    is exclusive of the CPU.  This series introduces a mechanism to
    temporarily unmap pages granting exclusive access to a device.
    
    These changes are required to support OpenCL atomic operations in Nouveau
    to shared virtual memory (SVM) regions allocated with the
    CL_MEM_SVM_ATOMICS clSVMAlloc flag.  A more complete description of the
    OpenCL SVM feature is available at
    https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/
    OpenCL_API.html#_shared_virtual_memory .
    
    Implementation
    ==============
    
    Exclusive device access is implemented by adding a new swap entry type
    (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry.  The main
    difference is that on fault the original entry is immediately restored by
    the fault handler instead of waiting.
    
    Restoring the entry triggers calls to MMU notifers which allows a device
    driver to revoke the atomic access permission from the GPU prior to the
    CPU finalising the entry.
    
    Patches
    =======
    
    Patches 1 & 2 refactor existing migration and device private entry
    functions.
    
    Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated
    functionality into separate functions - try_to_migrate_one() and
    try_to_munlock_one().
    
    Patch 5 renames some existing code but does not introduce functionality.
    
    Patch 6 is a small clean-up to swap entry handling in copy_pte_range().
    
    Patch 7 contains the bulk of the implementation for device exclusive
    memory.
    
    Patch 8 contains some additions to the HMM selftests to ensure everything
    works as expected.
    
    Patch 9 is a cleanup for the Nouveau SVM implementation.
    
    Patch 10 contains the implementation of atomic access for the Nouveau
    driver.
    
    Testing
    =======
    
    This has been tested with upstream Mesa 21.1.0 and a simple OpenCL program
    which checks that GPU atomic accesses to system memory are atomic.
    Without this series the test fails as there is no way of write-protecting
    the page mapping which results in the device clobbering CPU writes.  For
    reference the test is available at
    https://ozlabs.org/~apopple/opencl_svm_atomics/
    
    Further testing has been performed by adding support for testing exclusive
    access to the hmm-tests kselftests.
    
    This patch (of 10):
    
    Remove multiple similar inline functions for dealing with different types
    of special swap entries.
    
    Both migration and device private swap entries use the swap offset to
    store a pfn.  Instead of multiple inline functions to obtain a struct page
    for each swap entry type use a common function pfn_swap_entry_to_page().
    Also open-code the various entry_to_pfn() functions as this results is
    shorter code that is easier to understand.
    
    Link: https://lkml.kernel.org/r/20210616105937.23201-1-apopple@nvidia.com
    Link: https://lkml.kernel.org/r/20210616105937.23201-2-apopple@nvidia.comSigned-off-by: default avatarAlistair Popple <apopple@nvidia.com>
    Reviewed-by: default avatarRalph Campbell <rcampbell@nvidia.com>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Ben Skeggs <bskeggs@redhat.com>
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    af5cdaf8
huge_memory.c 86 KB