All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Usama Arif <usama.arif@bytedance.com>
Cc: linux-mm@kvack.org, muchun.song@linux.dev,
	mike.kravetz@oracle.com, linux-kernel@vger.kernel.org,
	fam.zheng@bytedance.com, liangma@liangbit.com,
	simon.evans@bytedance.com, punit.agrawal@bytedance.com
Subject: Re: [v1 5/6] mm: move allocation of gigantic hstates to the start of mm_core_init
Date: Sat, 29 Jul 2023 10:34:16 +0300	[thread overview]
Message-ID: <20230729073416.GG1901145@kernel.org> (raw)
In-Reply-To: <20230727204624.1942372-6-usama.arif@bytedance.com>

On Thu, Jul 27, 2023 at 09:46:23PM +0100, Usama Arif wrote:
> Whether the initialization of tail struct pages of a hugepage
> happens or not will become dependent on the commandline
> parameter hugetlb_free_vmemmap in the future. Hence,
> hugetlb_hstate_alloc_pages needs to be after command line parameters
> are parsed and the start of mm_core_init is a good point.
> 
> Signed-off-by: Usama Arif <usama.arif@bytedance.com>
> ---
>  include/linux/hugetlb.h |  1 +
>  mm/hugetlb.c            | 18 ++++++++++--------
>  mm/mm_init.c            |  4 ++++
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index ca3c8e10f24a..2b20553deef3 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1271,4 +1271,5 @@ hugetlb_walk(struct vm_area_struct *vma, unsigned long addr, unsigned long sz)
>  	return huge_pte_offset(vma->vm_mm, addr, sz);
>  }
>  
> +void __init hugetlb_hstate_alloc_gigantic_pages(void);

this should be in mm/internal.h with a static inline stub for !CONFIG_HUGETLBFS

>  #endif /* _LINUX_HUGETLB_H */
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 58cf5978bee1..c1fcf2af591a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4418,14 +4418,6 @@ static int __init hugepages_setup(char *s)
>  		}
>  	}
>  
> -	/*
> -	 * Global state is always initialized later in hugetlb_init.
> -	 * But we need to allocate gigantic hstates here early to still
> -	 * use the bootmem allocator.
> -	 */
> -	if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate))
> -		hugetlb_hstate_alloc_pages(parsed_hstate);
> -
>  	last_mhp = mhp;
>  
>  	return 1;
> @@ -4437,6 +4429,16 @@ static int __init hugepages_setup(char *s)
>  }
>  __setup("hugepages=", hugepages_setup);
>  
> +void __init hugetlb_hstate_alloc_gigantic_pages(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < HUGE_MAX_HSTATE; i++) {
> +		if (hstate_is_gigantic(&hstates[i]))
> +			hugetlb_hstate_alloc_pages(&hstates[i]);
> +	}
> +}
> +
>  /*
>   * hugepagesz command line processing
>   * A specific huge page size can only be specified once with hugepagesz.
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index a1963c3322af..5585c66c3c42 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -26,6 +26,7 @@
>  #include <linux/pgtable.h>
>  #include <linux/swap.h>
>  #include <linux/cma.h>
> +#include <linux/hugetlb.h>
>  #include "internal.h"
>  #include "slab.h"
>  #include "shuffle.h"
> @@ -2768,6 +2769,9 @@ static void __init mem_init_print_info(void)
>   */
>  void __init mm_core_init(void)
>  {
> +#ifdef CONFIG_HUGETLBFS
> +	hugetlb_hstate_alloc_gigantic_pages();
> +#endif

Please add a comment why it should be called here.

>  	/* Initializations relying on SMP setup */
>  	build_all_zonelists(NULL);
>  	page_alloc_init_cpuhp();
> -- 
> 2.25.1
> 

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2023-07-29  7:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 20:46 [v1 0/6] mm/memblock: Skip prep and initialization of struct pages freed later by HVO Usama Arif
2023-07-27 20:46 ` [v1 1/6] mm: hugetlb: Skip prep of tail pages when HVO is enabled Usama Arif
2023-07-28  8:18   ` kernel test robot
2023-07-28 11:26   ` kernel test robot
2023-07-29  6:37   ` Mike Rapoport
2023-07-27 20:46 ` [v1 2/6] mm: hugetlb_vmemmap: Use nid of the head page to reallocate it Usama Arif
2023-07-27 20:46 ` [v1 3/6] memblock: add parameter to memblock_setclr_flag for selecting memblock_type Usama Arif
2023-07-29  6:42   ` Mike Rapoport
2023-07-27 20:46 ` [v1 4/6] memblock: introduce MEMBLOCK_RSRV_NOINIT flag Usama Arif
2023-07-28  4:30   ` Mika Penttilä
2023-07-28 13:47     ` [External] " Usama Arif
2023-07-28 15:51       ` Mika Penttilä
2023-07-29  6:58   ` Mike Rapoport
2023-07-27 20:46 ` [v1 5/6] mm: move allocation of gigantic hstates to the start of mm_core_init Usama Arif
2023-07-29  7:34   ` Mike Rapoport [this message]
2023-07-27 20:46 ` [v1 6/6] mm: hugetlb: Skip initialization of struct pages freed later by HVO Usama Arif
2023-07-28 16:33   ` kernel test robot
2023-07-28 17:25   ` kernel test robot

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=20230729073416.GG1901145@kernel.org \
    --to=rppt@kernel.org \
    --cc=fam.zheng@bytedance.com \
    --cc=liangma@liangbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=punit.agrawal@bytedance.com \
    --cc=simon.evans@bytedance.com \
    --cc=usama.arif@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.