Re: [PATCH 2/5] mm/khugepaged: use slab cache instead of normal kmalloc

[Luka Bai]

在 Thu, Jun 11, 2026 at 01:35:46PM +0900，Harry Yoo 写道：

Hi Harry,

Thanks for the review.

> 
> 
> On 6/11/26 12:16 PM, Luka Bai wrote:
> > 在 Tue, Jun 09, 2026 at 12:26:18PM +0200，Vlastimil Babka (SUSE) 写道：
> >> On 5/31/26 06:23, Luka Bai wrote:
> >>> From: Luka Bai <lukabai@xxxxxxxxxxx>
> >>>
> >>> We added a kmem slab cached called collapse_hint_cache for
> >>> khugepaged collapse hint, to improve the performance in allocation
> >>> and freeing for the hint structs.
> >>>
> >>> Signed-off-by: Luka Bai <lukabai@xxxxxxxxxxx>
> >>
> >> Khugepaged isn't exactly a hotpath? Adding own cache comes with memory
> >> overhead, so this doesn't seem like a sufficient reason to do that.
> >>
> > Hi Vlastimil,
> > 
> > Thanks for the review :).
> > 
> > Yeah Khugepaged is not a hotpath. But in my implementation we will allocate
> > those khugepaged collapse hint structs in other paths like walk_mm() and
> > lru_gen_look_around(), which may be called more frequently under memory
> > pressure. I'm a little afraid that directly using kmalloc may compromise
> > the performance of reclaimation... What do you think? Thanks. :)
> 
> What makes you think using kmalloc compromises the performance under
> memory pressure?
> 

Sorry, I didn't do a comparison test for slab_cache against kmalloc to be honest so
this conclusion may be not very rigorous :). I just analyzed from the implementation.
Since khugepaged collapse hint is just a "best-effort" implementation so I don't want
it to influence other more important procedures and that's why I wanted to use the
fastest way for it.

1. Using individual slab_cache can help it use its own locks and slab caches from
what I see. So maybe we can improve performance by reducing the lock contention?
And I found that mm_slot used by khugepaged is also using its own slab_cache. My hint
struct should be allocated much more frequently than mm_slot during mglru scanning.
So that's why I said that "using kmalloc for khugepaged hint struct may compromise
the performance compared to using slab_cache", still, that's just a guess. :)

2. We can also save the fraction since kmalloc only has caches for sizes in a power
of 2 if I remember it correctly, while khugepaged collapse hint struct has a size of
48 bytes. So maybe using a individual slab cache could be helpful to the fraction.
Of course this reason is not as important as the first one.

I didn't realize using individual slab cache can have that much negative influence :)
Maybe I should actually do a comparison test for these two machanisms. Thanks.

> > Best regards,
> > Luka
> 
> -- 
> Cheers,
> Harry / Hyeonggon

Best regards,
Luka