[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ab7690d-aa21-0fd9-75f1-f3a23b892853@redhat.com>
Date: Fri, 24 Sep 2021 11:36:46 +0200
From: David Hildenbrand <david@...hat.com>
To: Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: Michal Hocko <mhocko@...e.com>, Oscar Salvador <osalvador@...e.de>,
Zi Yan <ziy@...dia.com>,
Muchun Song <songmuchun@...edance.com>,
Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
David Rientjes <rientjes@...gle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 2/4] hugetlb: add HPageCma flag and code to free
non-gigantic pages in CMA
On 23.09.21 19:53, 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.
>
> In order to track hugetlb pages that need to be returned to CMA, add the
> hugetlb specific flag HPageCma. Flag is set when a huge page is
> allocated from CMA and transferred to any demoted pages. Non-gigantic
> huge page freeing code checks for the flag and takes appropriate action.
Do we really need that flag or couldn't we simply always try
cma_release() and fallback to out ordinary freeing-path?
IIRC, cma knows exactly if something was allocated via a CMA are and can
be free via it. No need for additional tracking usually.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists