linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pingfan Liu <kernelfans@gmail.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@techsingularity.net>, Jan Kara <jack@suse.cz>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Michal Hocko <mhocko@suse.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm/migrate: see hole as invalid source page
Date: Mon, 26 Aug 2019 15:52:51 +0800	[thread overview]
Message-ID: <20190826075251.GA7486@mypc> (raw)
In-Reply-To: <20190816150222.GA10855@mypc>

On Fri, Aug 16, 2019 at 11:02:22PM +0800, Pingfan Liu wrote:
> On Thu, Aug 15, 2019 at 01:22:22PM -0400, Jerome Glisse wrote:
> > On Tue, Aug 06, 2019 at 04:00:10PM +0800, Pingfan Liu wrote:
> > > MIGRATE_PFN_MIGRATE marks a valid pfn, further more, suitable to migrate.
> > > As for hole, there is no valid pfn, not to mention migration.
> > > 
> > > Before this patch, hole has already relied on the following code to be
> > > filtered out. Hence it is more reasonable to see hole as invalid source
> > > page.
> > > migrate_vma_prepare()
> > > {
> > > 		struct page *page = migrate_pfn_to_page(migrate->src[i]);
> > > 
> > > 		if (!page || (migrate->src[i] & MIGRATE_PFN_MIGRATE))
> > > 		     \_ this condition
> > > }
> > 
> > NAK you break the API, MIGRATE_PFN_MIGRATE is use for 2 things,
> > first it allow the collection code to mark entry that can be
> > migrated, then it use by driver to allow driver to skip migration
> > for some entry (for whatever reason the driver might have), we
> > still need to keep the entry and not clear it so that we can
> > cleanup thing (ie remove migration pte entry).
> Thanks for your kindly review.
> 
> I read the code again. Maybe I miss something. But as my understanding,
> for hole, there is no pte.
> As the current code migrate_vma_collect_pmd()
> {
> 	if (pmd_none(*pmdp))
> 		return migrate_vma_collect_hole(start, end, walk);
> ...
> 	make_migration_entry()
> }
> 
> We do not install migration entry for hole, then no need to remove
> migration pte entry.
> 
> And on the driver side, there is way to migrate a hole. The driver just
> skip it by
> drivers/gpu/drm/nouveau/nouveau_dmem.c: if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE))
>                                              ^^^^
> Finally, in migrate_vma_finalize(), for a hole,
> 		if (!page) {
> 			if (newpage) {
> 				unlock_page(newpage);
> 				put_page(newpage);
> 			}
> 			continue;
> 		}
> And we do not rely on remove_migration_ptes(page, newpage, false); to
> restore the orignal pte (and it is impossible).
> 
Hello, do you have any comment?

I think most of important, hole does not use the 'MIGRATE_PFN_MIGRATE'
API. Hole has not pte, and there is no way to 'remove migration pte
entry'. Further more, we can know the failure on the source side, no
need to defer it to driver side.

By this way, [3/3] can unify the code.

Thanks,
	Pingfan

  reply	other threads:[~2019-08-26  7:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06  8:00 [PATCH 1/3] mm/migrate: clean up useless code in migrate_vma_collect_pmd() Pingfan Liu
2019-08-06  8:00 ` [PATCH 2/3] mm/migrate: see hole as invalid source page Pingfan Liu
2019-08-15 17:22   ` Jerome Glisse
2019-08-16 15:02     ` Pingfan Liu
2019-08-26  7:52       ` Pingfan Liu [this message]
2019-08-06  8:00 ` [PATCH 3/3] mm/migrate: remove the duplicated code migrate_vma_collect_hole() Pingfan Liu
2019-08-15 17:22   ` Jerome Glisse
2019-08-06 13:35 ` [PATCH 1/3] mm/migrate: clean up useless code in migrate_vma_collect_pmd() Matthew Wilcox
2019-08-07  5:28   ` Pingfan Liu
2019-08-07  8:41     ` [PATCHv2] " Pingfan Liu
2019-08-14 23:11       ` Ralph Campbell
2019-08-15 17:19       ` Jerome Glisse
2019-08-15 19:23         ` Ralph Campbell
2019-08-15 19:40           ` Jerome Glisse
2019-08-16 13:21             ` Pingfan Liu

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=20190826075251.GA7486@mypc \
    --to=kernelfans@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=jglisse@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).