Re: [PATCH v4 5/8] hugetlb: batch freeing of vmemmap pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/19/23 14:09, Muchun Song wrote:
> 
> 
> On 2023/9/19 07:01, Mike Kravetz wrote:
> > Now that batching of hugetlb vmemmap optimization processing is possible,
> > batch the freeing of vmemmap pages.  When freeing vmemmap pages for a
> > hugetlb page, we add them to a list that is freed after the entire batch
> > has been processed.
> > 
> > This enhances the ability to return contiguous ranges of memory to the
> > low level allocators.
> > 
> > Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> 
> Reviewed-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> 
> One nit bellow.
> 
> > ---
> >   mm/hugetlb_vmemmap.c | 85 ++++++++++++++++++++++++++++++--------------
> >   1 file changed, 59 insertions(+), 26 deletions(-)
> > 
> > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> > index 463a4037ec6e..147ed15bcae4 100644
> > --- a/mm/hugetlb_vmemmap.c
> > +++ b/mm/hugetlb_vmemmap.c
> > @@ -222,6 +222,9 @@ static void free_vmemmap_page_list(struct list_head *list)
> >   {
> >   	struct page *page, *next;
> > +	if (list_empty(list))
> > +		return;
> 
> It seems unnecessary since the following "list_for_each_entry_safe"
> could handle empty-list case. Right?
> 

Yes, it is an over-optimization that is not really necessary.
I will remove it.

-- 
Mike Kravetz




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux