All of lore.kernel.org
 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: Wed, 9 Aug 2023 15:44:24 -0700	[thread overview]
Message-ID: <20230809224424.GB3537@monkey> (raw)
In-Reply-To: <20230809205316.GA3537@monkey>

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.

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.

BTW - hugetlb pages not migrated due to passing a tail page does not
seem to contribute to a 'Positive return value' indicating the number of
non-migrated pages.
-- 
Mike Kravetz


  reply	other threads:[~2023-08-09 22:46 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 [this message]
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
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=20230809224424.GB3537@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.