From: Michal Hocko <mhocko@suse.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Shakeel Butt <shakeelb@google.com>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
Muchun Song <songmuchun@bytedance.com>,
David Rientjes <rientjes@google.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
HORIGUCHI NAOYA <naoya.horiguchi@nec.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Waiman Long <longman@redhat.com>, Peter Xu <peterx@redhat.com>,
Mina Almasry <almasrymina@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 3/8] hugetlb: create remove_hugetlb_page() to separate functionality
Date: Mon, 22 Mar 2021 15:15:43 +0100 [thread overview]
Message-ID: <YFimj4UGBat8Tp/C@dhcp22.suse.cz> (raw)
In-Reply-To: <20210319224209.150047-4-mike.kravetz@oracle.com>
On Fri 19-03-21 15:42:04, Mike Kravetz wrote:
> The new remove_hugetlb_page() routine is designed to remove a hugetlb
> page from hugetlbfs processing. It will remove the page from the active
> or free list, update global counters and set the compound page
> destructor to NULL so that PageHuge() will return false for the 'page'.
> After this call, the 'page' can be treated as a normal compound page or
> a collection of base size pages.
>
> remove_hugetlb_page is to be called with the hugetlb_lock held.
>
> Creating this routine and separating functionality is in preparation for
> restructuring code to reduce lock hold times.
I like this! Counters handling both in __free_huge_page and
update_and_free_page is really confusing.
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> mm/hugetlb.c | 70 ++++++++++++++++++++++++++++++++++------------------
> 1 file changed, 46 insertions(+), 24 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c537274c2a38..ae185d3315e0 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1306,6 +1306,46 @@ static inline void destroy_compound_gigantic_page(struct page *page,
> unsigned int order) { }
> #endif
>
> +/*
> + * Remove hugetlb page from lists, and update dtor so that page appears
> + * as just a compound page. A reference is held on the page.
> + * NOTE: hugetlb specific page flags stored in page->private are not
> + * automatically cleared. These flags may be used in routines
> + * which operate on the resulting compound page.
> + *
> + * Must be called with hugetlb lock held.
> + */
> +static void remove_hugetlb_page(struct hstate *h, struct page *page,
> + bool adjust_surplus)
> +{
> + int nid = page_to_nid(page);
> +
I think we want lockdep_assert_held here. Lockdep asserts are not used
in this code but now that you are touching it then it is probably better
to start adding them. What do you think?
> + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
> + return;
> +
> + list_del(&page->lru);
> +
> + if (HPageFreed(page)) {
> + h->free_huge_pages--;
> + h->free_huge_pages_node[nid]--;
> + ClearHPageFreed(page);
> + }
> + if (adjust_surplus) {
> + h->surplus_huge_pages--;
> + h->surplus_huge_pages_node[nid]--;
> + }
> +
> + VM_BUG_ON_PAGE(hugetlb_cgroup_from_page(page), page);
> + VM_BUG_ON_PAGE(hugetlb_cgroup_from_page_rsvd(page), page);
> +
> + ClearHPageTemporary(page);
> + set_page_refcounted(page);
> + set_compound_page_dtor(page, NULL_COMPOUND_DTOR);
> +
> + h->nr_huge_pages--;
> + h->nr_huge_pages_node[nid]--;
> +}
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-03-22 14:15 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 22:42 [RFC PATCH 0/8] make hugetlb put_page safe for all calling contexts Mike Kravetz
2021-03-19 22:42 ` [RFC PATCH 1/8] hugetlb: add per-hstate mutex to synchronize user adjustments Mike Kravetz
2021-03-22 13:59 ` Michal Hocko
2021-03-22 16:57 ` Mike Kravetz
2021-03-23 7:48 ` Michal Hocko
2021-03-19 22:42 ` [RFC PATCH 2/8] hugetlb: recompute min_count when dropping hugetlb_lock Mike Kravetz
2021-03-22 14:07 ` Michal Hocko
2021-03-22 23:07 ` Mike Kravetz
2021-03-23 7:50 ` Michal Hocko
2021-03-23 8:01 ` Peter Zijlstra
2021-03-23 8:14 ` Michal Hocko
2021-03-23 23:18 ` Mike Kravetz
2021-03-24 8:36 ` Michal Hocko
2021-03-24 16:43 ` Mike Kravetz
2021-03-19 22:42 ` [RFC PATCH 3/8] hugetlb: create remove_hugetlb_page() to separate functionality Mike Kravetz
2021-03-22 14:15 ` Michal Hocko [this message]
2021-03-22 17:01 ` Mike Kravetz
2021-03-19 22:42 ` [RFC PATCH 4/8] hugetlb: call update_and_free_page without hugetlb_lock Mike Kravetz
2021-03-22 14:19 ` Michal Hocko
2021-03-19 22:42 ` [RFC PATCH 5/8] hugetlb: change free_pool_huge_page to remove_pool_huge_page Mike Kravetz
2021-03-22 14:31 ` Michal Hocko
2021-03-22 23:28 ` Mike Kravetz
2021-03-23 7:57 ` Michal Hocko
2021-03-24 1:03 ` Mike Kravetz
2021-03-24 8:40 ` Michal Hocko
2021-03-24 16:38 ` Mike Kravetz
2021-03-24 16:50 ` Michal Hocko
2021-03-19 22:42 ` [RFC PATCH 6/8] hugetlb: make free_huge_page irq safe Mike Kravetz
2021-03-21 19:55 ` Mike Kravetz
2021-03-22 13:36 ` [hugetlb] cd190f60f9: BUG:sleeping_function_called_from_invalid_context_at_mm/hugetlb.c kernel test robot
2021-03-22 14:35 ` [RFC PATCH 6/8] hugetlb: make free_huge_page irq safe Michal Hocko
2021-03-19 22:42 ` [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for irq context Mike Kravetz
2021-03-20 1:18 ` Hillf Danton
2021-03-25 0:26 ` Mike Kravetz
2021-03-22 8:41 ` Peter Zijlstra
2021-03-22 17:42 ` Mike Kravetz
2021-03-22 18:10 ` Roman Gushchin
2021-03-23 18:51 ` Mike Kravetz
2021-03-23 19:07 ` Roman Gushchin
2021-03-24 8:43 ` Michal Hocko
2021-03-24 16:53 ` Mike Kravetz
2021-03-22 20:43 ` Peter Zijlstra
2021-03-22 14:42 ` Michal Hocko
2021-03-22 14:46 ` Michal Hocko
2021-03-19 22:42 ` [RFC PATCH 8/8] hugetlb: track hugetlb pages allocated via cma_alloc Mike Kravetz
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=YFimj4UGBat8Tp/C@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=david@redhat.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=shakeelb@google.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).