From: Oscar Salvador <osalvador@suse.de>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Michal Hocko <mhocko@kernel.org>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Muchun Song <songmuchun@bytedance.com>,
David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 2/3] hugetlb: convert page_huge_active() to HPageMigratable flag
Date: Fri, 15 Jan 2021 21:38:03 +0100 [thread overview]
Message-ID: <20210115203803.GB3322@localhost.localdomain> (raw)
In-Reply-To: <d98039ef-8489-6d8c-a323-44e3f0d8acee@oracle.com>
On Fri, Jan 15, 2021 at 09:43:36AM -0800, Mike Kravetz wrote:
> > Before the page_huge_active() in scan_movable_pages() we have the
> > if (!PageHuge(page)) check, but could it be that between that check and
> > the page_huge_active(), the page gets dissolved, and so we are checking
> > a wrong page[1]? Am I making sense?
>
> Yes, you are making sense.
>
> The reason I decided to drop the check is because it does not eliminate the
> race. Even with that check in page_huge_active, the page could be dissolved
> between that check and check of page[1]. There really is no way to eliminate
> the race without holding a reference to the page (or hugetlb_lock). That
> check in page_huge_active just shortens the race window.
Yeah, you are right, the race already exists.
Anyway, do_migrate_range should take care of making sure what it is
handling, so I think we are good.
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-01-15 20:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 21:01 [RFC PATCH 0/3] create hugetlb flags to consolidate state Mike Kravetz
2021-01-11 21:01 ` [RFC PATCH 1/3] hugetlb: use page.private for hugetlb specific page flags Mike Kravetz
2021-01-12 3:24 ` [External] " Muchun Song
2021-01-12 5:23 ` kernel test robot
2021-01-13 13:54 ` Oscar Salvador
2021-01-13 17:49 ` Mike Kravetz
2021-01-13 14:45 ` Matthew Wilcox
2021-01-13 17:51 ` Mike Kravetz
2021-01-11 21:01 ` [RFC PATCH 2/3] hugetlb: convert page_huge_active() to HPageMigratable flag Mike Kravetz
2021-01-12 3:45 ` [External] " Muchun Song
2021-01-15 9:17 ` Oscar Salvador
2021-01-15 17:43 ` Mike Kravetz
2021-01-15 20:05 ` Mike Kravetz
2021-01-15 20:29 ` Oscar Salvador
2021-01-15 21:25 ` Mike Kravetz
2021-01-15 20:38 ` Oscar Salvador [this message]
2021-01-11 21:01 ` [RFC PATCH 3/3] hugetlb: convert PageHugeTemporary() to HPageTempSurplus Mike Kravetz
2021-01-15 10:16 ` Oscar Salvador
2021-01-15 17:47 ` Mike Kravetz
2021-01-12 10:41 ` [RFC PATCH 0/3] create hugetlb flags to consolidate state 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=20210115203803.GB3322@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=songmuchun@bytedance.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.