linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ralph Campbell <rcampbell@nvidia.com>
To: <jglisse@redhat.com>, <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	"Christian König" <christian.koenig@amd.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Jan Kara" <jack@suse.cz>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	"Jason Gunthorpe" <jgg@mellanox.com>,
	"Ross Zwisler" <zwisler@kernel.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-rdma@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums
Date: Fri, 22 Feb 2019 11:26:09 -0800	[thread overview]
Message-ID: <49d6489c-31b4-511b-2504-bc7aa5d44673@nvidia.com> (raw)
In-Reply-To: <20190219200430.11130-5-jglisse@redhat.com>


On 2/19/19 12:04 PM, jglisse@redhat.com wrote:
> From: Jérôme Glisse <jglisse@redhat.com>
> 
> CPU page table update can happens for many reasons, not only as a result

s/update/updates
s/happens/happen

> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
> 
> This patch introduce a set of enums that can be associated with each of

s/introduce/introduces

> the events triggering a mmu notifier. Latter patches take advantages of
> those enum values.

s/advantages/advantage

> 
>      - UNMAP: munmap() or mremap()
>      - CLEAR: page table is cleared (migration, compaction, reclaim, ...)
>      - PROTECTION_VMA: change in access protections for the range
>      - PROTECTION_PAGE: change in access protections for page in the range
>      - SOFT_DIRTY: soft dirtyness tracking
> 

s/dirtyness/dirtiness

> Being able to identify munmap() and mremap() from other reasons why the
> page table is cleared is important to allow user of mmu notifier to
> update their own internal tracking structure accordingly (on munmap or
> mremap it is not longer needed to track range of virtual address as it
> becomes invalid).
> 
> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Felix Kuehling <Felix.Kuehling@amd.com>
> Cc: Jason Gunthorpe <jgg@mellanox.com>
> Cc: Ross Zwisler <zwisler@kernel.org>
> 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: Ralph Campbell <rcampbell@nvidia.com>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: kvm@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rdma@vger.kernel.org
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
>   include/linux/mmu_notifier.h | 30 ++++++++++++++++++++++++++++++
>   1 file changed, 30 insertions(+)
> 
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index c8672c366f67..2386e71ac1b8 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -10,6 +10,36 @@
>   struct mmu_notifier;
>   struct mmu_notifier_ops;
>   
> +/**
> + * enum mmu_notifier_event - reason for the mmu notifier callback
> + * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that
> + * move the range

I would say something about the VMA for the notifier range
is being deleted.
MMU notifier clients can then use this case to remove any policy or
access counts associated with the range.
Just changing the PTE to "no access" as in the CLEAR case
doesn't mean a policy which prefers device private memory
over system memory should be cleared.

> + *
> + * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
> + * madvise() or replacing a page by another one, ...).
> + *
> + * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
> + * ie using the vma access permission (vm_page_prot) to update the whole range
> + * is enough no need to inspect changes to the CPU page table (mprotect()
> + * syscall)
> + *
> + * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
> + * pages in the range so to mirror those changes the user must inspect the CPU
> + * page table (from the end callback).
> + *
> + * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
> + * access flags). User should soft dirty the page in the end callback to make
> + * sure that anyone relying on soft dirtyness catch pages that might be written
> + * through non CPU mappings.
> + */
> +enum mmu_notifier_event {
> +	MMU_NOTIFY_UNMAP = 0,
> +	MMU_NOTIFY_CLEAR,
> +	MMU_NOTIFY_PROTECTION_VMA,
> +	MMU_NOTIFY_PROTECTION_PAGE,
> +	MMU_NOTIFY_SOFT_DIRTY,
> +};
> +
>   #ifdef CONFIG_MMU_NOTIFIER
>   
>   /*
> 


  reply	other threads:[~2019-02-22 19:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19 20:04 [PATCH v5 0/9] mmu notifier provide context informations jglisse
2019-02-19 20:04 ` [PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable jglisse
2019-02-22 19:01   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function jglisse
2019-02-22 19:02   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags jglisse
2019-02-22 19:04   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums jglisse
2019-02-22 19:26   ` Ralph Campbell [this message]
2019-02-19 20:04 ` [PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2 jglisse
2019-02-22 21:25   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation jglisse
2019-02-22 22:07   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2 jglisse
2019-02-22 22:08   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper jglisse
2019-02-22 22:42   ` Ralph Campbell
2019-02-19 20:04 ` [PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2 jglisse
2019-02-22 23:01   ` Ralph Campbell
2019-02-19 20:15 ` [PATCH v5 0/9] mmu notifier provide context informations Dan Williams
2019-02-19 20:30   ` Jerome Glisse
2019-02-19 20:40     ` Jason Gunthorpe
2019-02-19 20:49       ` Dan Williams
2019-02-19 20:40     ` Dan Williams
2019-02-19 20:57       ` Jerome Glisse
2019-02-19 21:19         ` Dan Williams
2019-02-19 21:30           ` Jerome Glisse

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=49d6489c-31b4-511b-2504-bc7aa5d44673@nvidia.com \
    --to=rcampbell@nvidia.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jack@suse.cz \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgg@mellanox.com \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=rodrigo.vivi@intel.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