linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Zi Yan <ziy@nvidia.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Huang Ying <ying.huang@intel.com>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration()
Date: Thu, 10 Aug 2023 09:29:20 -0700	[thread overview]
Message-ID: <20230810162920.GA4734@monkey> (raw)
In-Reply-To: <2da95492-079b-43b1-a950-d290984a21c0@huawei.com>

On 08/10/23 09:49, Kefeng Wang wrote:
> 
> 
> On 2023/8/10 6:44, Mike Kravetz wrote:
> > On 08/09/23 13:53, Mike Kravetz wrote:
> > > On 08/09/23 20:37, Kefeng Wang wrote:
> > > > > 
> > > > > Cc Mike to help us clarify the expected behavior of hugetlb.
> > > > > 
> > > > > Hi Mike, what is the expected behavior, if a user tries to use move_pages()
> > > > > to migrate a non head page of a hugetlb page?
> > > > 
> > > > Could you give some advise, thanks
> > > > 
> > > 
> > > Sorry, I was away for a while.
> > > 
> > > It seems unfortunate that move_pages says the passed user addresses
> > > should be aligned to page boundaries.  However, IIUC this is not checked
> > > or enforced.  Otherwise, passing a hugetlb page should return the same
> > > error.
> > > 
> > > One thought would be that hugetlb mappings should behave the same
> > > non-hugetlb mappings.  If passed the address of a hugetlb tail page, align
> > > the address to a hugetlb boundary and migrate the page.  This changes the
> > > existing behavior.  However, it would be hard to imagine anyone depending
> > > on this.
> > > 
> > > After taking a closer look at the add_page_for_migration(), it seems to
> > > just ignore passed tail pages and do nothing for such passed addresses.
> > > Correct?  Or, am I missing something?  Perhaps that is behavior we want/
> > > need to preserve?
> > 
> > My mistake, status -EACCES is returned when passing a tail page of a
> > hugetlb page.
> > 
> 
> As mentioned in previous mail, before e66f17ff7177 ("mm/hugetlb: take
> page table lock in follow_huge_pmd()") in v4.0, follow_page() will
> return NULL on tail page for Huagetlb page, so move_pages() will return
> -ENOENT errno, but after that commit, -EACCES is returned.
> 
> Meanwhile, the behavior of THP/HUGETLB is different, the whole THP will be
> migrated on a tail page, but HUGETLB will return -EACCES(after v4.0)
> or -ENOENT(before v4.0) on tail page.
> 
> > Back to the question of 'What is the expected behavior if a tail page is
> > passed?'.  I do not think we have defined an expected behavior.  If
> > anything is 'expected' I would say it is -EACCES as returned today.
> > 
> 
> My question is,
> 
> Should we keep seem behavior between HUGETLB and THP, or only change the
> errno from -EACCES to -ENOENT/-EBUSY.

Just to be clear.  When you say "keep seem behavior between HUGETLB and THP",
are you saying that you would like hugetlb to perform migration of the entire
hugetlb page if a tail page is passed?

IMO, this would be ideal as it would mean that hugetlb and THP behave the same
when passed the address of a tail page.  The fewer places where hugetlb
behavior diverges, the better.  However, this does change behavior.

As mentioned above, I have a hard time imagining someone depending on the
behavior that passing the address of a hugetlb tail page returns error.  But,
this is almost impossible to predict.

Thoughts from others?  
-- 
Mike Kravetz

> 
> I would like to drop PageHead() check for Hugetlb to keep seem behavior,
> which will keep seem error code if isolate fail or success on head/tail
> page.
> 
> Thanks.


  reply	other threads:[~2023-08-10 16:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02  9:53 [PATCH 0/4] mm: migrate: more folio conversion Kefeng Wang
2023-08-02  9:53 ` [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration() Kefeng Wang
2023-08-02 12:21   ` Matthew Wilcox
2023-08-03  7:13     ` Kefeng Wang
2023-08-03 12:30       ` Matthew Wilcox
2023-08-04  1:45         ` Kefeng Wang
2023-08-04  2:42           ` Zi Yan
2023-08-04  5:54             ` Kefeng Wang
2023-08-07 12:20               ` Kefeng Wang
2023-08-07 18:45                 ` Zi Yan
2023-08-09 12:37                   ` Kefeng Wang
2023-08-09 20:53                     ` Mike Kravetz
2023-08-09 22:44                       ` Mike Kravetz
2023-08-10  1:49                         ` Kefeng Wang
2023-08-10 16:29                           ` Mike Kravetz [this message]
2023-08-15  3:58                             ` Huang, Ying
2023-08-15 21:12                               ` Mike Kravetz
2023-08-16  0:50                                 ` Kefeng Wang
2023-08-15  3:56               ` Huang, Ying
2023-08-15 13:49                 ` Zi Yan
2023-08-15 20:39                   ` Huang, Ying
2023-08-02  9:53 ` [PATCH 2/4] mm: migrate: convert numamigrate_isolate_page() to numamigrate_isolate_folio() Kefeng Wang
2023-08-02 12:30   ` Matthew Wilcox
2023-08-03  7:08     ` Kefeng Wang
2023-08-06  5:04       ` Hugh Dickins
2023-08-02  9:53 ` [PATCH 3/4] mm: migrate: make migrate_misplaced_page() to take a folio Kefeng Wang
2023-08-02  9:53 ` [PATCH 4/4] mm: migrate: use __folio_test_movable() Kefeng Wang
2023-08-02 12:37   ` Matthew Wilcox
2023-08-02 12:38   ` David Hildenbrand
2023-08-02 11:47 ` [PATCH 0/4] mm: migrate: more folio conversion David Hildenbrand
2023-08-02 12:38   ` Kefeng Wang
2023-08-03  9:34     ` David Hildenbrand

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=20230810162920.GA4734@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=ziy@nvidia.com \
    /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