All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>, 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,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration()
Date: Tue, 15 Aug 2023 14:12:26 -0700	[thread overview]
Message-ID: <20230815211226.GA4150@monkey> (raw)
In-Reply-To: <87wmxx7y9j.fsf@yhuang6-desk2.ccr.corp.intel.com>

On 08/15/23 11:58, Huang, Ying wrote:
> Mike Kravetz <mike.kravetz@oracle.com> writes:
> 
> > 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.
> 
> A separate patch will be needed for behavior change.
> 

Correct.

Since the goal of this series is to convert to folios, we should maintain the
existing behavior and errno (-EACCES).  In a subsequent patch, we can
change behavior.

That would be my suggestion.
-- 
Mike Kravetz


  reply	other threads:[~2023-08-15 21:12 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
2023-08-15  3:58                             ` Huang, Ying
2023-08-15 21:12                               ` Mike Kravetz [this message]
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=20230815211226.GA4150@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.