From: Mike Kravetz <mike.kravetz@oracle.com>
To: Oscar Salvador <osalvador@suse.de>
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 1/5] hugetlb: add demote hugetlb page sysfs interfaces
Date: Mon, 4 Oct 2021 11:27:36 -0700 [thread overview]
Message-ID: <81c2e7d0-cbdf-56fd-2a59-34c180d5a979@oracle.com> (raw)
In-Reply-To: <YVr7C8ek1g9hKz4C@localhost.localdomain>
On 10/4/21 6:00 AM, Oscar Salvador wrote:
> On Fri, Oct 01, 2021 at 10:52:06AM -0700, Mike Kravetz wrote:
>> -which function as described above for the default huge page-sized case.
>> +The demote interfaces provide the ability to split a huge page into
>> +smaller huge pages. For example, the x86 architecture supports both
>> +1GB and 2MB huge pages sizes. A 1GB huge page can be split into 512
>> +2MB huge pages. Demote interfaces are not available for the smallest
>> +huge page size. The demote interfaces are:
>> +
>> +demote_size
>> + is the size of demoted pages. When a page is demoted a corresponding
>> + number of huge pages of demote_size will be created. By default,
>> + demote_size is set to the next smaller huge page size. If there are
>> + multiple smaller huge page sizes, demote_size can be set to any of
>> + these smaller sizes. Only huge page sizes less then the current huge
>
> s/then/than ?
>
Thanks
>> static void __init hugetlb_init_hstates(void)
>> {
>> - struct hstate *h;
>> + struct hstate *h, *h2;
>>
>> for_each_hstate(h) {
>> if (minimum_order > huge_page_order(h))
>> @@ -2995,6 +2995,23 @@ static void __init hugetlb_init_hstates(void)
>> /* oversize hugepages were init'ed in early boot */
>> if (!hstate_is_gigantic(h))
>> hugetlb_hstate_alloc_pages(h);
>> +
>> + /*
>> + * Set demote order for each hstate. Note that
>> + * h->demote_order is initially 0.
>> + * - We can not demote gigantic pages if runtime freeing
>> + * is not supported.
>> + */
>> + if (!hstate_is_gigantic(h) ||
>> + gigantic_page_runtime_supported()) {
>
> Based on the comment, I think that making the condition explicit looks
> better from my point of view.
>
> if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
> continue;
>
Agreed. In addition, this code will look better when more conditions
are added in subsequent patches.
--
Mike Kravetz
>> + for_each_hstate(h2) {
>> + if (h2 == h)
>> + continue;
>> + if (h2->order < h->order &&
>> + h2->order > h->demote_order)
>> + h->demote_order = h2->order;
>> + }
>> + }
>> }
>> VM_BUG_ON(minimum_order == UINT_MAX);
>> }
>> @@ -3235,9 +3252,29 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
>> return 0;
>> }
>>
next prev parent reply other threads:[~2021-10-04 18:27 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 [this message]
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
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=81c2e7d0-cbdf-56fd-2a59-34c180d5a979@oracle.com \
--to=mike.kravetz@oracle.com \
--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=naoya.horiguchi@linux.dev \
--cc=osalvador@suse.de \
--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).