Re: [RFC PATCH 0/3] mmu_notifier contextual information

["Christian König" <christian.koenig@amd.com>]

Am 23.03.2018 um 18:17 schrieb jglisse@redhat.com:
> From: Jérôme Glisse <jglisse@redhat.com>
>
> This patchset are the improvements to mmu_notifier i wish to discuss
> at next LSF/MM. I am sending now to give time to people to look at
> them and think about them.
>
> git://people.freedesktop.org/~glisse/linux mmu-notifier-rfc
> https://cgit.freedesktop.org/~glisse/linux/log/?h=mmu-notifier-rfc
>
> First patch just use a struct for invalidate_range_start/end arguments
> this make the other 2 patches easier and smaller.
>
> The idea is to provide more information to mmu_notifier listener on
> the context of each invalidation. When a range is invalidated this
> can be for various reasons (munmap, protection change, OOM, ...). If
> listener can distinguish between those it can take better action.
>
> For instance if device driver allocate structure to track a range of
> virtual address prior to this patch it always have to assume that it
> has to free those on each mmu_notifieir callback (having to assume it
> is a munmap) and reallocate those latter when the device try to do
> something with that range again.
>
> OOM is also an interesting case, recently a patchset was added to
> avoid OOM on a mm if a blocking mmu_notifier listener have been
> registered [1]. This can be improve by adding a new OOM event type and
> having listener take special path on those. All mmu_notifier i know
> can easily have a special path for OOM that do not block (beside
> taking a short lived, across driver, spinlock). If mmu_notifier usage
> grows (from a point of view of more process using devices that rely on
> them) then we should also make sure OOM can do its bidding.

+1 for better handling that.

The fact that the OOM killer now avoids processes which might sleep 
during their MM destruction gave me a few sleepless night recently.

Christian.

>
>
> The last part of the patchset is to allow more concurrency between a
> range being invalidated and someone wanting to look at CPU page table
> for a different range of address. I don't have any benchmark for those
> but i expect this will be common with HMM and mirror once we can run
> real workload. It can also replace lot of custom and weird counting
> of active mmu_notifier done listener side (KVM, ODP, ...) with some-
> thing cleaner.
>
>
> I have try to leverage all this in KVM but it did not seems to give any
> significant performance improvements (KVM patches at [2]). Tested with
> the host kernel using this patchset and KVM patches, and running thing
> like kernel compilation in the guest. Maybe it is not the kind of work-
> load that can benefit from this.
>
>
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1712.1/02108.html
> [2] https://cgit.freedesktop.org/~glisse/linux/log/?h=mmu-notifier-rfc-kvm
>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>
> Cc: Artemy Kovalyov <artemyko@mellanox.com>
> Cc: Evgeny Baskakov <ebaskakov@nvidia.com>
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> Cc: Mark Hairgrove <mhairgrove@nvidia.com>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
> Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Dimitri Sivanich <sivanich@sgi.com>
>
> Jérôme Glisse (3):
>    mm/mmu_notifier: use struct for invalidate_range_start/end parameters
>    mm/mmu_notifier: provide context information about range invalidation
>    mm/mmu_notifier: keep track of ranges being invalidated
>
>   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  |  17 ++---
>   drivers/gpu/drm/i915/i915_gem_userptr.c |  13 ++--
>   drivers/gpu/drm/radeon/radeon_mn.c      |  11 +--
>   drivers/infiniband/core/umem_odp.c      |  16 ++--
>   drivers/infiniband/hw/hfi1/mmu_rb.c     |  12 ++-
>   drivers/misc/mic/scif/scif_dma.c        |  10 +--
>   drivers/misc/sgi-gru/grutlbpurge.c      |  13 ++--
>   drivers/xen/gntdev.c                    |   7 +-
>   fs/dax.c                                |   8 +-
>   fs/proc/task_mmu.c                      |   8 +-
>   include/linux/mm.h                      |   3 +-
>   include/linux/mmu_notifier.h            | 129 ++++++++++++++++++++++++++------
>   kernel/events/uprobes.c                 |  11 +--
>   mm/hmm.c                                |  15 ++--
>   mm/huge_memory.c                        |  69 +++++++++--------
>   mm/hugetlb.c                            |  47 ++++++------
>   mm/khugepaged.c                         |  12 +--
>   mm/ksm.c                                |  24 +++---
>   mm/madvise.c                            |  21 +++---
>   mm/memory.c                             |  97 +++++++++++++-----------
>   mm/migrate.c                            |  47 ++++++------
>   mm/mmu_notifier.c                       |  44 +++++++++--
>   mm/mprotect.c                           |  14 ++--
>   mm/mremap.c                             |  12 +--
>   mm/oom_kill.c                           |  19 +++--
>   mm/rmap.c                               |  22 ++++--
>   virt/kvm/kvm_main.c                     |  12 +--
>   27 files changed, 420 insertions(+), 293 deletions(-)
>