[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181204152137.5e6791987739fd64ce7ea421@linux-foundation.org>
Date: Tue, 4 Dec 2018 15:21:37 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: jglisse@...hat.com
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Matthew Wilcox <mawilcox@...rosoft.com>,
Ross Zwisler <zwisler@...nel.org>, Jan Kara <jack@...e.cz>,
Dan Williams <dan.j.williams@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Michal Hocko <mhocko@...nel.org>,
Christian Koenig <christian.koenig@....com>,
Felix Kuehling <felix.kuehling@....com>,
Ralph Campbell <rcampbell@...dia.com>,
John Hubbard <jhubbard@...dia.com>, kvm@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-fsdevel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event
triggering invalidation
On Mon, 3 Dec 2018 15:18:17 -0500 jglisse@...hat.com wrote:
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
>
> Users of mmu notifier API track changes to the CPU page table and take
> specific action for them. While current API only provide range of virtual
> address affected by the change, not why the changes is happening.
>
> This patchset adds event information so that users of mmu notifier can
> differentiate among broad category:
> - 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
>
> 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).
>
> ...
>
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -519,6 +519,7 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
> struct mmu_notifier_range range;
> struct mmu_gather tlb;
>
> + range.event = MMU_NOTIFY_CLEAR;
> range.start = vma->vm_start;
> range.end = vma->vm_end;
> range.mm = mm;
mmu_notifier_range and MMU_NOTIFY_CLEAR aren't defined if
CONFIG_MMU_NOTIFIER=n.
I'll try a temporary bodge:
+++ a/include/linux/mmu_notifier.h
@@ -10,8 +10,6 @@
struct mmu_notifier;
struct mmu_notifier_ops;
-#ifdef CONFIG_MMU_NOTIFIER
-
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -32,6 +30,8 @@ struct mmu_notifier_range {
bool blockable;
};
+#ifdef CONFIG_MMU_NOTIFIER
+
struct mmu_notifier_ops {
/*
* Called either by mmu_notifier_unregister or when the mm is
But this new code should vanish altogether if CONFIG_MMU_NOTIFIER=n,
please. Or at least, we shouldn't be unnecessarily initializing .mm
and .event. Please take a look at debloating this code.
Powered by blists - more mailing lists