[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200728191940.GB159104@nvidia.com>
Date: Tue, 28 Jul 2020 16:19:40 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Ralph Campbell <rcampbell@...dia.com>
CC: <linux-rdma@...r.kernel.org>, <linux-mm@...ck.org>,
<nouveau@...ts.freedesktop.org>, <kvm-ppc@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Jerome Glisse <jglisse@...hat.com>,
John Hubbard <jhubbard@...dia.com>,
Christoph Hellwig <hch@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
Shuah Khan <shuah@...nel.org>, Ben Skeggs <bskeggs@...hat.com>,
Bharata B Rao <bharata@...ux.ibm.com>
Subject: Re: [PATCH v4 6/6] mm/migrate: remove range invalidation in
migrate_vma_pages()
On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote:
> When migrating the special zero page, migrate_vma_pages() calls
> mmu_notifier_invalidate_range_start() before replacing the zero page
> PFN in the CPU page tables. This is unnecessary since the range was
> invalidated in migrate_vma_setup() and the page table entry is checked
> to be sure it hasn't changed between migrate_vma_setup() and
> migrate_vma_pages(). Therefore, remove the redundant invalidation.
I don't follow this logic, the purpose of the invalidation is also to
clear out anything that may be mirroring this VA, and "the page hasn't
changed" doesn't seem to rule out that case?
I'm also not sure I follow where the zero page came from?
Jason
Powered by blists - more mailing lists