From: "Koenig, Christian" <Christian.Koenig@amd.com>
To: "jglisse@redhat.com" <jglisse@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Matthew Wilcox" <mawilcox@microsoft.com>,
"Ross Zwisler" <zwisler@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Dan Williams" <dan.j.williams@intel.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Kuehling, Felix" <Felix.Kuehling@amd.com>,
"Ralph Campbell" <rcampbell@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] mmu notifier contextual informations
Date: Tue, 4 Dec 2018 07:35:22 +0000 [thread overview]
Message-ID: <2c0ed01b-50f9-961b-ff08-de494e00b1b4@amd.com> (raw)
In-Reply-To: <20181203201817.10759-1-jglisse@redhat.com>
Am 03.12.18 um 21:18 schrieb jglisse@redhat.com:
> From: Jérôme Glisse <jglisse@redhat.com>
>
> This patchset add contextual information, why an invalidation is
> happening, to mmu notifier callback. This is necessary for user
> of mmu notifier that wish to maintains their own data structure
> without having to add new fields to struct vm_area_struct (vma).
>
> For instance device can have they own page table that mirror the
> process address space. When a vma is unmap (munmap() syscall) the
> device driver can free the device page table for the range.
>
> Today we do not have any information on why a mmu notifier call
> back is happening and thus device driver have to assume that it
> is always an munmap(). This is inefficient at it means that it
> needs to re-allocate device page table on next page fault and
> rebuild the whole device driver data structure for the range.
>
> Other use case beside munmap() also exist, for instance it is
> pointless for device driver to invalidate the device page table
> when the invalidation is for the soft dirtyness tracking. Or
> device driver can optimize away mprotect() that change the page
> table permission access for the range.
>
> This patchset enable all this optimizations for device driver.
> I do not include any of those in this serie but other patchset
> i am posting will leverage this.
>
>
> From code point of view the patchset is pretty simple, the first
> two patches consolidate all mmu notifier arguments into a struct
> so that it is easier to add/change arguments. The last patch adds
> the contextual information (munmap, protection, soft dirty, clear,
> ...).
Skimming over it at least the parts I'm familiar with look completely
sane to me.
Whole series is Acked-by: Christian König <christian.koenig@amd.com>.
Regards,
Christian.
>
> Cheers,
> Jérôme
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Matthew Wilcox <mawilcox@microsoft.com>
> Cc: Ross Zwisler <zwisler@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krčmář <rkrcmar@redhat.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Felix Kuehling <felix.kuehling@amd.com>
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: kvm@vger.kernel.org
> Cc: linux-rdma@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
>
> Jérôme Glisse (3):
> mm/mmu_notifier: use structure for invalidate_range_start/end callback
> mm/mmu_notifier: use structure for invalidate_range_start/end calls
> mm/mmu_notifier: contextual information for event triggering
> invalidation
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 43 ++++-----
> drivers/gpu/drm/i915/i915_gem_userptr.c | 14 ++-
> drivers/gpu/drm/radeon/radeon_mn.c | 16 ++--
> drivers/infiniband/core/umem_odp.c | 20 ++---
> drivers/infiniband/hw/hfi1/mmu_rb.c | 13 ++-
> drivers/misc/mic/scif/scif_dma.c | 11 +--
> drivers/misc/sgi-gru/grutlbpurge.c | 14 ++-
> drivers/xen/gntdev.c | 12 +--
> fs/dax.c | 11 ++-
> fs/proc/task_mmu.c | 10 ++-
> include/linux/mm.h | 4 +-
> include/linux/mmu_notifier.h | 106 +++++++++++++++-------
> kernel/events/uprobes.c | 13 +--
> mm/hmm.c | 23 ++---
> mm/huge_memory.c | 58 ++++++------
> mm/hugetlb.c | 63 +++++++------
> mm/khugepaged.c | 13 +--
> mm/ksm.c | 26 +++---
> mm/madvise.c | 22 ++---
> mm/memory.c | 112 ++++++++++++++----------
> mm/migrate.c | 30 ++++---
> mm/mmu_notifier.c | 22 +++--
> mm/mprotect.c | 17 ++--
> mm/mremap.c | 14 +--
> mm/oom_kill.c | 20 +++--
> mm/rmap.c | 34 ++++---
> virt/kvm/kvm_main.c | 14 ++-
> 27 files changed, 421 insertions(+), 334 deletions(-)
>
prev parent reply other threads:[~2018-12-04 7:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 20:18 jglisse
2018-12-03 20:18 ` [PATCH 1/3] mm/mmu_notifier: use structure for invalidate_range_start/end callback jglisse
2018-12-03 20:18 ` [PATCH 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls jglisse
2018-12-04 0:09 ` Jerome Glisse
2018-12-05 11:04 ` Jan Kara
2018-12-05 15:53 ` Jerome Glisse
2018-12-05 16:28 ` Jan Kara
2018-12-06 20:31 ` kbuild test robot
2018-12-06 20:35 ` kbuild test robot
2018-12-03 20:18 ` [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation jglisse
2018-12-04 8:17 ` Mike Rapoport
2018-12-04 14:48 ` Jerome Glisse
2018-12-04 23:21 ` Andrew Morton
2018-12-06 20:53 ` kbuild test robot
2018-12-06 21:19 ` kbuild test robot
2018-12-06 21:51 ` Jerome Glisse
2018-12-04 7:35 ` Koenig, Christian [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c0ed01b-50f9-961b-ff08-de494e00b1b4@amd.com \
--to=christian.koenig@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jack@suse.cz \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=mhocko@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rcampbell@nvidia.com \
--cc=rkrcmar@redhat.com \
--cc=zwisler@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox