[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CCCD27BE-0127-4148-92A8-673075A976E0@linux.dev>
Date: Wed, 19 Jul 2023 11:35:44 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: Mike Kravetz <mike.kravetz@...cle.com>
Cc: Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Jiaqi Yan <jiaqiyan@...gle.com>,
Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
Muchun Song <songmuchun@...edance.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Axel Rasmussen <axelrasmussen@...gle.com>,
James Houghton <jthoughton@...gle.com>,
Michal Hocko <mhocko@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 2/2] hugetlb: optimize update_and_free_pages_bulk to
avoid lock cycles
> On Jul 18, 2023, at 08:49, Mike Kravetz <mike.kravetz@...cle.com> wrote:
>
> update_and_free_pages_bulk is designed to free a list of hugetlb pages
> back to their associated lower level allocators. This may require
> allocating vmemmmap pages associated with each hugetlb page. The
> hugetlb page destructor must be changed before pages are freed to lower
> level allocators. However, the destructor must be changed under the
> hugetlb lock. This means there is potentially one lock cycle per page.
>
> Minimize the number of lock cycles in update_and_free_pages_bulk by:
> 1) allocating necessary vmemmap for all hugetlb pages on the list
> 2) take hugetlb lock and clear destructor for all pages on the list
> 3) free all pages on list back to low level allocators
>
> Signed-off-by: Mike Kravetz <mike.kravetz@...cle.com>
Reviewed-by: Muchun Song <songmuchun@...edance.com>
Thanks.
Powered by blists - more mailing lists