* [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table
@ 2026-10-06 16:01 Dheeraj Kumar Srivastava
2026-10-06 16:09 ` Dheeraj Kumar Srivastava
2026-10-07 5:10 ` Muchun Song
0 siblings, 2 replies; 3+ messages in thread
From: Dheeraj Kumar Srivastava @ 2026-10-06 16:01 UTC (permalink / raw)
To: muchun.song, osalvador, david, akpm, davidlohr, linux-mm, linux-kernel
Cc: dheerajkumar.srivastava, Vasant.Hegde, bharata
On systems/VMs with a large number of CPUs (e.g. 4096), hugetlb_init()
computes num_fault_mutexes = roundup_pow_of_two(8 * num_possible_cpus())
= 32768. The subsequent kmalloc for the mutex table can exceed
MAX_PAGE_ORDER when struct mutex is enlarged by debug options like
CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC, resulting in:
WARNING: at __alloc_frozen_pages_noprof (order > MAX_PAGE_ORDER)
kernel BUG at mm/hugetlb.c (BUG_ON(!hugetlb_fault_mutex_table))
Kernel panic - not syncing: Fatal exception
Switch to kvmalloc_objs() so the allocation falls back to vmalloc when
the contiguous physical allocation is too large. The table is only
accessed by index, so virtual contiguity is sufficient.
Fixes: 8382d914ebf7 ("mm, hugetlb: improve page-fault scalability")
Signed-off-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index cea25773a6c9..6fc5c0bdb500 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4177,7 +4177,7 @@ static int __init hugetlb_init(void)
num_fault_mutexes = 1;
#endif
hugetlb_fault_mutex_table =
- kmalloc_objs(struct mutex, num_fault_mutexes);
+ kvmalloc_objs(struct mutex, num_fault_mutexes);
BUG_ON(!hugetlb_fault_mutex_table);
for (i = 0; i < num_fault_mutexes; i++)
--
2.25.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table
2026-10-06 16:01 [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table Dheeraj Kumar Srivastava
@ 2026-10-06 16:09 ` Dheeraj Kumar Srivastava
2026-10-07 5:10 ` Muchun Song
1 sibling, 0 replies; 3+ messages in thread
From: Dheeraj Kumar Srivastava @ 2026-10-06 16:09 UTC (permalink / raw)
To: muchun.song, osalvador, david, akpm, davidlohr, linux-mm, linux-kernel
Cc: Vasant.Hegde, bharata
Hi all,
On 10/6/2026 9:31 PM, Dheeraj Kumar Srivastava wrote:
> On systems/VMs with a large number of CPUs (e.g. 4096), hugetlb_init()
> computes num_fault_mutexes = roundup_pow_of_two(8 * num_possible_cpus())
> = 32768. The subsequent kmalloc for the mutex table can exceed
> MAX_PAGE_ORDER when struct mutex is enlarged by debug options like
> CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC, resulting in:
>
> WARNING: at __alloc_frozen_pages_noprof (order > MAX_PAGE_ORDER)
> kernel BUG at mm/hugetlb.c (BUG_ON(!hugetlb_fault_mutex_table))
> Kernel panic - not syncing: Fatal exception
>
> Switch to kvmalloc_objs() so the allocation falls back to vmalloc when
> the contiguous physical allocation is too large. The table is only
> accessed by index, so virtual contiguity is sufficient.
Sorry, I forgot to include the "Changes since v1" change log.
Changes since v1:
-> Use kvmalloc_objs() instead of kvmalloc_array().
Thanks
Dheeraj
>
> Fixes: 8382d914ebf7 ("mm, hugetlb: improve page-fault scalability")
> Signed-off-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
> ---
> mm/hugetlb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cea25773a6c9..6fc5c0bdb500 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4177,7 +4177,7 @@ static int __init hugetlb_init(void)
> num_fault_mutexes = 1;
> #endif
> hugetlb_fault_mutex_table =
> - kmalloc_objs(struct mutex, num_fault_mutexes);
> + kvmalloc_objs(struct mutex, num_fault_mutexes);
> BUG_ON(!hugetlb_fault_mutex_table);
>
> for (i = 0; i < num_fault_mutexes; i++)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table
2026-10-06 16:01 [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table Dheeraj Kumar Srivastava
2026-10-06 16:09 ` Dheeraj Kumar Srivastava
@ 2026-10-07 5:10 ` Muchun Song
1 sibling, 0 replies; 3+ messages in thread
From: Muchun Song @ 2026-10-07 5:10 UTC (permalink / raw)
To: Dheeraj Kumar Srivastava
Cc: osalvador, david, akpm, davidlohr, linux-mm, linux-kernel,
Vasant.Hegde, bharata, dheerajkumar.srivastava
> On Oct 6, 2026, at 18:02, Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com> wrote:
>
> On systems/VMs with a large number of CPUs (e.g. 4096), hugetlb_init()
> computes num_fault_mutexes = roundup_pow_of_two(8 * num_possible_cpus())
> = 32768. The subsequent kmalloc for the mutex table can exceed
> MAX_PAGE_ORDER when struct mutex is enlarged by debug options like
> CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC, resulting in:
>
> WARNING: at __alloc_frozen_pages_noprof (order > MAX_PAGE_ORDER)
> kernel BUG at mm/hugetlb.c (BUG_ON(!hugetlb_fault_mutex_table))
> Kernel panic - not syncing: Fatal exception
>
> Switch to kvmalloc_objs() so the allocation falls back to vmalloc when
> the contiguous physical allocation is too large. The table is only
> accessed by index, so virtual contiguity is sufficient.
>
> Fixes: 8382d914ebf7 ("mm, hugetlb: improve page-fault scalability")
> Signed-off-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Thanks for your fix.
Acked-by: Muchun Song <muchun.song@linux.dev>
Thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-07 6:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-06 16:01 [PATCH v2] mm/hugetlb: use kvmalloc_objs for hugetlb_fault_mutex_table Dheeraj Kumar Srivastava
2026-10-06 16:09 ` Dheeraj Kumar Srivastava
2026-10-07 5:10 ` Muchun Song
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®