Re: [PATCH] mm/zblock: use vmalloc for page allocations

[Johannes Weiner <hannes@cmpxchg.org>]

On Sat, May 03, 2025 at 08:46:07PM +0200, Vitaly Wool wrote:
> 
> 
> > On May 2, 2025, at 10:07 AM, Igor Belousov <igor.b@beldev.am> wrote:
> > 
> > On 2025-05-02 12:01, Vitaly Wool wrote:
> >> From: Igor Belousov <igor.b@beldev.am>
> >> Use vmalloc for page allocations for zblock blocks to avoid extra
> >> pressure on the memmory subsystem with multiple higher order
> >> allocations.
> >> While at it, introduce a module parameter to opportunistically
> >> allocate pages of lower orders via try_page_alloc() for faster
> >> allocations whenever possible.
> >> Since vmalloc works fine with non-power of 2 numbers of pages,
> >> rewrite the block size tables to use that opportunity.
> >> Signed-off-by: Igor Belousov <igor.b@beldev.am>
> >> Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.se>
> >> ---
> >> Tests run on qemu-arm64 (8 CPUs, 1.5G RAM, 4K pages):
> >> 1. zblock
> >> 43205.38user
> >> 7320.53system
> >> 2:12:04elapsed
> >> zswpin 346127
> >> zswpout 1642438
> >> 2. zsmalloc
> >> 47194.61user
> >> 7978.48system
> >> 2:25:03elapsed
> >> zswpin 448031
> >> zswpout 1810485
> >> So zblock gives a nearly 10% advantage.
> >> Please note that zsmalloc *crashes* on 16K page tests so I couldn't
> >> compare performance in that case.
> > 
> > Right, and it looks like this:
> > 
> > [  762.499278]  bug_handler+0x0/0xa8
> > [  762.499433]  die_kernel_fault+0x1c4/0x36c
> > [  762.499616]  fault_from_pkey+0x0/0x98
> > [  762.499784]  do_translation_fault+0x3c/0x94
> > [  762.499969]  do_mem_abort+0x44/0x94
> > [  762.500140]  el1_abort+0x40/0x64
> > [  762.500306]  el1h_64_sync_handler+0xa4/0x120
> > [  762.500502]  el1h_64_sync+0x6c/0x70
> > [  762.500718]  __pi_memcpy_generic+0x1e4/0x22c (P)
> > [  762.500931]  zs_zpool_obj_write+0x10/0x1c
> > [  762.501117]  zpool_obj_write+0x18/0x24
> > [  762.501305]  zswap_store+0x490/0x7c4
> > [  762.501474]  swap_writepage+0x260/0x448
> > [  762.501654]  pageout+0x148/0x340
> > [  762.501816]  shrink_folio_list+0xa7c/0xf34
> > [  762.502008]  shrink_lruvec+0x6fc/0xbd0
> > [  762.502189]  shrink_node+0x52c/0x960
> > [  762.502359]  balance_pgdat+0x344/0x738
> > [  762.502537]  kswapd+0x210/0x37c
> > [  762.502691]  kthread+0x12c/0x204
> > [  762.502920]  ret_from_fork+0x10/0x20
> 
> In fact we don’t know if zsmalloc is actually supposed to work with
> 16K pages. That’s the question to Sergey and Minchan. If it is
> indeed supposed to handle 16K pages, I would suggest that you
> submitted a full report with reproduction steps and/or provided a
> fix if possible.

I've been using zsmalloc with 16k pages just fine for ~a year,
currently running it on 6.14.2-asahi. This machine sees a lot of
memory pressure, too.

Could this be a more recent regression, maybe in the new obj_write()?