From: Oscar Salvador <osalvador@suse.de>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Michal Hocko <mhocko@suse.com>, Zi Yan <ziy@nvidia.com>,
Muchun Song <songmuchun@bytedance.com>,
Naoya Horiguchi <naoya.horiguchi@linux.dev>,
David Rientjes <rientjes@google.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 3/5] hugetlb: be sure to free demoted CMA pages to CMA
Date: Tue, 5 Oct 2021 11:33:21 +0200 [thread overview]
Message-ID: <20211005093320.GC20412@linux> (raw)
In-Reply-To: <20211001175210.45968-4-mike.kravetz@oracle.com>
On Fri, Oct 01, 2021 at 10:52:08AM -0700, Mike Kravetz wrote:
> When huge page demotion is fully implemented, gigantic pages can be
> demoted to a smaller huge page size. For example, on x86 a 1G page
> can be demoted to 512 2M pages. However, gigantic pages can potentially
> be allocated from CMA. If a gigantic page which was allocated from CMA
> is demoted, the corresponding demoted pages needs to be returned to CMA.
>
> Use the new interface cma_pages_valid() to determine if a non-gigantic
> hugetlb page should be freed to CMA. Also, clear mapping field of these
> pages as expected by cma_release.
>
> This also requires a change to CMA reservations for gigantic pages.
> Currently, the 'order_per_bit' is set to the gigantic page size.
> However, if gigantic pages can be demoted this needs to be set to the
> order of the smallest huge page. At CMA reservation time we do not know
to the smallest, or to the next smaller? Would you mind elaborating why?
> @@ -3003,7 +3020,8 @@ static void __init hugetlb_init_hstates(void)
> * is not supported.
> */
> if (!hstate_is_gigantic(h) ||
> - gigantic_page_runtime_supported()) {
> + gigantic_page_runtime_supported() ||
> + !hugetlb_cma_size || !(h->order <= HUGETLB_PAGE_ORDER)) {
I am bit lost in the CMA area, so bear with me.
We do not allow to demote if we specify we want hugetlb pages from the CMA?
Also, can h->order be smaller than HUGETLB_PAGE_ORDER? I though
HUGETLB_PAGE_ORDER was the smallest one.
The check for HUGETLB_PAGE_ORDER can probably be squashed into patch#1.
> for_each_hstate(h2) {
> if (h2 == h)
> continue;
> @@ -3555,6 +3573,8 @@ static ssize_t demote_size_store(struct kobject *kobj,
> if (!t_hstate)
> return -EINVAL;
> demote_order = t_hstate->order;
> + if (demote_order < HUGETLB_PAGE_ORDER)
> + return -EINVAL;
This could probably go in the first patch.
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2021-10-05 9:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 17:52 [PATCH v3 0/5] hugetlb: add demote/split page functionality Mike Kravetz
2021-10-01 17:52 ` [PATCH v3 1/5] hugetlb: add demote hugetlb page sysfs interfaces Mike Kravetz
2021-10-04 13:00 ` Oscar Salvador
2021-10-04 18:27 ` Mike Kravetz
2021-10-05 8:23 ` Oscar Salvador
2021-10-05 16:58 ` Mike Kravetz
2021-10-01 17:52 ` [PATCH v3 2/5] mm/cma: add cma_pages_valid to determine if pages are in CMA Mike Kravetz
2021-10-05 8:45 ` Oscar Salvador
2021-10-05 17:06 ` Mike Kravetz
2021-10-05 8:48 ` David Hildenbrand
2021-10-01 17:52 ` [PATCH v3 3/5] hugetlb: be sure to free demoted CMA pages to CMA Mike Kravetz
2021-10-05 9:33 ` Oscar Salvador [this message]
2021-10-05 18:57 ` Mike Kravetz
2021-10-06 7:54 ` Oscar Salvador
2021-10-06 18:27 ` Mike Kravetz
2021-10-01 17:52 ` [PATCH v3 4/5] hugetlb: add demote bool to gigantic page routines Mike Kravetz
2021-10-01 17:52 ` [PATCH v3 5/5] hugetlb: add hugetlb demote page support Mike Kravetz
2021-10-06 8:41 ` Oscar Salvador
2021-10-06 18:52 ` Mike Kravetz
2021-10-07 7:52 ` Oscar Salvador
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=20211005093320.GC20412@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@linux.dev \
--cc=rientjes@google.com \
--cc=songmuchun@bytedance.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 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).