[Intel-xe] ✗ CI.checkpatch: warning for drm/xe: Support optional pinning of userptr pages (rev2)

[Patchwork]

== Series Details ==

Series: drm/xe: Support optional pinning of userptr pages (rev2)
URL   : https://patchwork.freedesktop.org/series/122637/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
e700ea2f248a75138759bcb443affeef4a2d1991
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit a3b91acf797c1b38fbff5082db4bd081be5c58cb
Author: Thomas Hellström <thomas.hellstrom at linux.intel.com>
Date:   Tue Aug 22 18:21:36 2023 +0200

    drm/xe/uapi: Support pinning of userptr vmas
    
    Support pinning of vmas using XE_VM_BIND_FLAG_PIN, initially for userptr
    only. Pinned memory becomes accounted against RLIMIT_MEMLOCK and processes
    with CAP_IPC_LOCK will not apply the limit. This is pretty similar to
    mlock()'ing userptr memory with the added benefit that the driver is
    aware and can ignore some actions in the MMU invalidation notifier.
    
    This will initially become useful for compute VMs on hardware without
    mid-thread-preemption capability since with pinned pages, the MMU
    invalidation notifier never tries to preempt a running compute kernel.
    
    If that were the only usage we could restrict this to a flag that always
    pins userptr VMAs on compute VMs on such hardware, but there are
    indications that this may become needed in other situations as well.
    
    From a more general point of view, the usage pattern of a system may be
    such that in most cases it only ever runs a single workload per system
    and then the sysadmin would want to configure the system to allow
    extensive pinning for performance reasons.
    
    Hence we might want to extend the pinning capability to bo-backed VMAs
    as well. How that pinning will be accounted remains an open but to build
    on the current drm CGROUP work would be an option.
    
    Signed-off-by: Thomas Hellström <thomas.hellstrom at linux.intel.com>
    Reviewed-by: Matthew Brost <matthew.brost at intel.com>
+ /mt/dim checkpatch 779f35314dba1441d29f4cfd510e7beb73c5f615 drm-intel
/mt/dim: line 50: /root/.dimrc: No such file or directory