linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Muchun Song <songmuchun@bytedance.com>
To: corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, viro@zeniv.linux.org.uk,
	akpm@linux-foundation.org, paulmck@kernel.org,
	mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com,
	rdunlap@infradead.org, oneukum@suse.com,
	anshuman.khandual@arm.com, jroedel@suse.de,
	almasrymina@google.com, rientjes@google.com, willy@infradead.org,
	osalvador@suse.de, mhocko@suse.com, song.bao.hua@hisilicon.com,
	david@redhat.com, naoya.horiguchi@nec.com
Cc: duanxiongchun@bytedance.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	Muchun Song <songmuchun@bytedance.com>
Subject: [PATCH v13 08/12] mm: hugetlb: introduce PageHugeInflight
Date: Sun, 17 Jan 2021 23:10:49 +0800	[thread overview]
Message-ID: <20210117151053.24600-9-songmuchun@bytedance.com> (raw)
In-Reply-To: <20210117151053.24600-1-songmuchun@bytedance.com>

When we free a HugeTLB page whose vmemmap pages can be optimized,
it is freed to the buddy allocator through a kworker. And the ref
count of page is zero, so if we dissolve it before it is freed to
the buddy allocator. It can be freed again. In order to avoid
this, we introduce PageHugeInflight to indicate that the HugeTLB
page is already freed from hugepage pool but not freed to buddy
allocator yet. When we hit the inflight page, we just need to flush
the work.

Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
 mm/hugetlb.c | 38 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3222bad8b112..14549204ddcb 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1343,6 +1343,36 @@ static inline void flush_hpage_update_work(struct hstate *h)
 		flush_work(&hpage_update_work);
 }
 
+#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
+static inline bool PageHugeInflight(struct page *head)
+{
+	return page_private(head + 5) == -1UL;
+}
+
+static inline void SetPageHugeInflight(struct page *head)
+{
+	set_page_private(head + 5, -1UL);
+}
+
+static inline void ClearPageHugeInflight(struct page *head)
+{
+	set_page_private(head + 5, 0);
+}
+#else
+static inline bool PageHugeInflight(struct page *head)
+{
+	return false;
+}
+
+static inline void SetPageHugeInflight(struct page *head)
+{
+}
+
+static inline void ClearPageHugeInflight(struct page *head)
+{
+}
+#endif
+
 static inline void __update_and_free_page(struct hstate *h, struct page *page)
 {
 	/* No need to allocate vmemmap pages */
@@ -1351,6 +1381,8 @@ static inline void __update_and_free_page(struct hstate *h, struct page *page)
 		return;
 	}
 
+	SetPageHugeInflight(page);
+
 	/*
 	 * Defer freeing to avoid using GFP_ATOMIC to allocate vmemmap
 	 * pages.
@@ -1637,6 +1669,7 @@ static void prep_new_huge_page(struct hstate *h, struct page *page, int nid)
 {
 	free_huge_page_vmemmap(h, page);
 
+	ClearPageHugeInflight(page);
 	INIT_LIST_HEAD(&page->lru);
 	set_compound_page_dtor(page, HUGETLB_PAGE_DTOR);
 	set_hugetlb_cgroup(page, NULL);
@@ -1913,13 +1946,16 @@ int dissolve_free_huge_page(struct page *page)
 		if (h->free_huge_pages - h->resv_huge_pages == 0)
 			goto out;
 
+		rc = 0;
 		hwpoison_subpage_set(h, head, page);
+		if (PageHugeInflight(head))
+			goto out;
+
 		list_del(&head->lru);
 		h->free_huge_pages--;
 		h->free_huge_pages_node[nid]--;
 		h->max_huge_pages--;
 		update_and_free_page(h, head);
-		rc = 0;
 	}
 out:
 	spin_unlock(&hugetlb_lock);
-- 
2.11.0



  parent reply	other threads:[~2021-01-17 15:15 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 15:10 [PATCH v13 00/12] Free some vmemmap pages of HugeTLB page Muchun Song
2021-01-17 15:10 ` [PATCH v13 01/12] mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c Muchun Song
2021-01-25  2:48   ` Miaohe Lin
2021-01-17 15:10 ` [PATCH v13 02/12] mm: hugetlb: introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2021-01-24 23:58   ` David Rientjes
2021-01-25  3:16     ` Randy Dunlap
2021-01-25  4:06     ` [External] " Muchun Song
2021-01-25  4:08       ` Randy Dunlap
2021-01-25  5:06         ` Muchun Song
2021-01-25 18:47           ` David Rientjes
2021-01-26  2:45             ` Muchun Song
2021-01-26 20:13               ` David Rientjes
2021-01-26  2:07   ` Miaohe Lin
2021-01-17 15:10 ` [PATCH v13 03/12] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page Muchun Song
2021-01-17 15:29   ` Muchun Song
2021-01-23  0:59   ` Mike Kravetz
2021-01-23  3:22     ` [External] " Muchun Song
2021-01-23 17:52   ` Oscar Salvador
2021-01-24  6:48     ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 04/12] mm: hugetlb: defer freeing of HugeTLB pages Muchun Song
2021-01-24 23:55   ` David Rientjes
2021-01-25  3:58     ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 05/12] mm: hugetlb: allocate the vmemmap pages associated with each HugeTLB page Muchun Song
2021-01-25  0:05   ` David Rientjes
2021-01-25  6:40     ` [External] " Muchun Song
2021-01-25  7:41       ` Muchun Song
2021-01-25  9:15         ` David Hildenbrand
2021-01-25  9:34           ` Muchun Song
2021-01-25 23:25             ` Mike Kravetz
2021-01-26  7:48               ` Oscar Salvador
2021-01-26  9:29   ` Oscar Salvador
2021-01-26  9:36     ` David Hildenbrand
2021-01-26 14:58       ` Oscar Salvador
2021-01-26 15:10         ` David Hildenbrand
2021-01-26 15:34           ` Oscar Salvador
2021-01-26 15:56             ` David Hildenbrand
2021-01-27 10:36               ` David Hildenbrand
2021-01-28 12:37                 ` [External] " Muchun Song
2021-01-28 13:08                   ` Muchun Song
2021-01-29  1:04                   ` Mike Kravetz
2021-01-29  6:56                     ` Muchun Song
2021-02-01 16:10                     ` David Hildenbrand
2021-02-02  0:05                       ` Mike Kravetz
2021-01-28 22:29                 ` Oscar Salvador
2021-01-29  6:16                   ` [External] " Muchun Song
2021-02-01 15:50                   ` David Hildenbrand
2021-01-17 15:10 ` [PATCH v13 06/12] mm: hugetlb: set the PageHWPoison to the raw error page Muchun Song
2021-01-25  0:06   ` David Rientjes
2021-01-25  5:06     ` [External] " Muchun Song
2021-01-17 15:10 ` [PATCH v13 07/12] mm: hugetlb: flush work when dissolving a HugeTLB page Muchun Song
2021-01-17 15:10 ` Muchun Song [this message]
2021-01-17 15:10 ` [PATCH v13 09/12] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Muchun Song
2021-01-25 11:43   ` David Hildenbrand
2021-01-25 12:08     ` Oscar Salvador
2021-01-25 12:31       ` [External] " Muchun Song
2021-01-25 12:30     ` Muchun Song
2021-01-17 15:10 ` [PATCH v13 10/12] mm: hugetlb: introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2021-01-17 15:10 ` [PATCH v13 11/12] mm: hugetlb: gather discrete indexes of tail page Muchun Song
2021-01-17 15:10 ` [PATCH v13 12/12] mm: hugetlb: optimize the code with the help of the compiler Muchun Song
2021-01-20 12:52 ` [PATCH v13 00/12] Free some vmemmap pages of HugeTLB page Muchun Song
2021-01-20 13:10   ` Oscar Salvador
2021-01-20 14:22     ` [External] " Muchun Song

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=20210117151053.24600-9-songmuchun@bytedance.com \
    --to=songmuchun@bytedance.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=hpa@zytor.com \
    --cc=jroedel@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=oneukum@suse.com \
    --cc=osalvador@suse.de \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=x86@kernel.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