From: Muchun Song <muchun.song@linux.dev>
To: Gang Li <gang.li@linux.dev>
Cc: Gang Li <ligang.bdlg@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Randy Dunlap <rdunlap@infradead.org>,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 1/1] hugetlb: fix CONFIG_PADATA dependency for non-SMP system
Date: Sun, 4 Feb 2024 15:44:26 +0800 [thread overview]
Message-ID: <f05f658a-78fa-45cd-ad07-11d87b824702@linux.dev> (raw)
In-Reply-To: <20240204072525.1986626-1-gang.li@linux.dev>
On 2024/2/4 15:25, Gang Li wrote:
> Randy Dunlap and kernel test robot reported a warning:
>
> ```
> WARNING: unmet direct dependencies detected for PADATA
> Depends on [n]: SMP [=n]
> Selected by [y]:
> - HUGETLBFS [=y] && (X86 [=y] || SPARC64 || ARCH_SUPPORTS_HUGETLBFS [=n] || BROKEN [=n]) && (SYSFS [=y] || SYSCTL [=n])
> ```
>
> hugetlb parallelization depends on PADATA, and PADATA depends on SMP, so
> when the SMP config is disabled, the dependency of hugetlb on padata
> should be downgraded to single thread.
>
> Fixes: f2f635264b98 ("hugetlb: have CONFIG_HUGETLBFS select CONFIG_PADATA")
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Closes: https://lore.kernel.org/lkml/ec5dc528-2c3c-4444-9e88-d2c48395b433@infradead.org/
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202402020454.6EPkP1hi-lkp@intel.com/
> Signed-off-by: Gang Li <ligang.bdlg@bytedance.com>
> ```
> Hi Andrew, this fix patch is based on mm/mm-unstable.
> Thanks!
> ```
> ---
> fs/Kconfig | 2 +-
> mm/hugetlb.c | 9 ++++++++-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 3abc107ab2fbd..f2bc73fc0417e 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -261,7 +261,7 @@ menuconfig HUGETLBFS
> depends on X86 || SPARC64 || ARCH_SUPPORTS_HUGETLBFS || BROKEN
> depends on (SYSFS || SYSCTL)
> select MEMFD_CREATE
> - select PADATA
> + select PADATA if SMP
I don't think it is a clear way to fix this. If someone want to
use PADATA in a non-SMP system, he should be carefully to handle
the non-SMP case himself. I think the better way is to make PADATA
handle the non-SMP case, I think it should be easy for it, which
could just call ->thread_fn() many times instead of creating many
threads in the non-SMP case.
Thanks.
> help
> hugetlbfs is a filesystem backing for HugeTLB pages, based on
> ramfs. For architectures that support it, say Y here and read
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index bf3d5dfb921e6..1b01b244fb50b 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3457,6 +3457,7 @@ static void __init gather_bootmem_prealloc_node(unsigned long start, unsigned lo
>
> static void __init gather_bootmem_prealloc(void)
> {
> +#ifdef CONFIG_PADATA
> struct padata_mt_job job = {
> .thread_fn = gather_bootmem_prealloc_node,
> .fn_arg = NULL,
> @@ -3469,6 +3470,9 @@ static void __init gather_bootmem_prealloc(void)
> };
>
> padata_do_multithreaded(&job);
> +#else
> + gather_bootmem_prealloc_node(0, 0, NULL);
> +#endif
> }
>
> static void __init hugetlb_hstate_alloc_pages_onenode(struct hstate *h, int nid)
> @@ -3568,6 +3572,7 @@ static unsigned long __init hugetlb_gigantic_pages_alloc_boot(struct hstate *h)
>
> static unsigned long __init hugetlb_pages_alloc_boot(struct hstate *h)
> {
> +#ifdef CONFIG_PADATA
> struct padata_mt_job job = {
> .fn_arg = h,
> .align = 1,
> @@ -3600,7 +3605,9 @@ static unsigned long __init hugetlb_pages_alloc_boot(struct hstate *h)
> job.max_threads = num_node_state(N_MEMORY) * 2;
> job.min_chunk = h->max_huge_pages / num_node_state(N_MEMORY) / 2;
> padata_do_multithreaded(&job);
> -
> +#else
> + hugetlb_pages_alloc_boot_node(0, h->max_huge_pages, h);
> +#endif
> return h->nr_huge_pages;
> }
>
next prev parent reply other threads:[~2024-02-04 7:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-04 7:25 [PATCH 1/1] hugetlb: fix CONFIG_PADATA dependency for non-SMP system Gang Li
2024-02-04 7:44 ` Muchun Song [this message]
2024-02-04 7:48 ` Gang Li
2024-02-05 6:55 ` Gang Li
2024-02-05 7:37 ` Muchun Song
2024-02-05 8:08 ` Gang Li
-- strict thread matches above, loose matches on Subject: below --
2024-02-08 2:39 Muchun Song
2024-02-10 2:45 ` Muchun Song
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=f05f658a-78fa-45cd-ad07-11d87b824702@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=gang.li@linux.dev \
--cc=ligang.bdlg@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=rdunlap@infradead.org \
/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.