linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, songmuchun@bytedance.com,
	jhubbard@nvidia.com
Subject: Re: [PATCH mm-unstable v2 8/8] mm/hugetlb: convert demote_free_huge_page to folios
Date: Wed, 18 Jan 2023 10:56:07 +0900	[thread overview]
Message-ID: <20230118015607.GA1620837@u2004> (raw)
In-Reply-To: <2f9ef115-a508-090b-d804-23235a447063@oracle.com>

On Fri, Jan 13, 2023 at 09:16:23AM -0600, Sidhartha Kumar wrote:
> On 1/10/23 6:00 PM, Mike Kravetz wrote:
> > On 01/10/23 21:40, Matthew Wilcox wrote:
> > > On Tue, Jan 10, 2023 at 03:28:21PM -0600, Sidhartha Kumar wrote:
> > > > @@ -3505,6 +3505,7 @@ static int demote_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
> > > >   {
> > > >   	int nr_nodes, node;
> > > >   	struct page *page;
> > > > +	struct folio *folio;
> > > >   	lockdep_assert_held(&hugetlb_lock);
> > > > @@ -3518,8 +3519,8 @@ static int demote_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
> > > >   		list_for_each_entry(page, &h->hugepage_freelists[node], lru) {
> > > >   			if (PageHWPoison(page))
> > > >   				continue;
> > > > -
> > > > -			return demote_free_huge_page(h, page);
> > > > +			folio = page_folio(page);
> > > > +			return demote_free_hugetlb_folio(h, folio);
> > > >   		}
> > > >   	}
> > > 
> > > Can't this be
> > > 		list_for_each_entry(folio, &h->hugepage_freelists[node], lru)
> > > 
> > > which avoids the call to page_folio() here.
> > > 
> > > I think the call to PageHWPoison is actually wrong here.  That would
> > > only check the hwpoison bit on the first page, whereas we want to know
> > > about the hwpoison bit on any page (don't we?)  So this should be
> > > folio_test_has_hwpoisoned()?
> > > 
> > > Or is that a THP-thing that is different for hugetlb pages?
> > 
> > I believe it is different for hugetlb pages.  See hugetlb_set_page_hwpoison()
> > where it sets PageHWPoison on head page as well as allocating a raw_hwp_page
> 
> I agree, this line in hugetlb_set_page_hwpoison (which is now
> folio_set_hugetlb_hwpoison) sets the HWPoison flag on the head page
> 
> int ret = folio_test_set_hwpoison(folio) ? -EHWPOISON : 0;
> 
> so the correct code in demote_pool_huge_page() would be:
> 
> 	list_for_each_entry(folio, &h->hugepage_freelists[node], lru) {
> 			if (folio_test_hwpoison(folio))
> 				continue;
> 			return demote_free_hugetlb_folio(h, folio);
> 		}
> 
> 
> > to track the actual page with poison.  Note that we can not directly flag
> > hugetlb 'subpages' because we may not have the struct pages due to vmemmap
> > optimization.  Adding Naoya just to be sure.

Yes, the above code and the reason totally make sense to me.
Thanks for the patch and the update.

- Naoya Horiguchif


      reply	other threads:[~2023-01-18  1:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 21:28 [PATCH mm-unstable v2 0/8] continue hugetlb folio conversion Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 1/8] mm/hugetlb: convert isolate_hugetlb to folios Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 2/8] mm/hugetlb: convert __update_and_free_page() " Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 3/8] mm/hugetlb: convert dequeue_hugetlb_page functions " Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 4/8] mm/hugetlb: convert alloc_surplus_huge_page() " Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 5/8] mm/hugetlb: increase use of folios in alloc_huge_page() Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 6/8] mm/hugetlb: convert alloc_migrate_huge_page to folios Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 7/8] mm/hugetlb: convert restore_reserve_on_error() " Sidhartha Kumar
2023-01-10 21:28 ` [PATCH mm-unstable v2 8/8] mm/hugetlb: convert demote_free_huge_page " Sidhartha Kumar
2023-01-10 21:40   ` Matthew Wilcox
2023-01-11  0:00     ` Mike Kravetz
2023-01-13 15:16       ` Sidhartha Kumar
2023-01-18  1:56         ` Naoya Horiguchi [this message]

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=20230118015607.GA1620837@u2004 \
    --to=naoya.horiguchi@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=sidhartha.kumar@oracle.com \
    --cc=songmuchun@bytedance.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).