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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fddf0457275576c890d16921465cf473@beldev.am>
Date: Fri, 02 May 2025 12:07:27 +0400
From: Igor Belousov <igor.b@...dev.am>
To: Vitaly Wool <vitaly.wool@...sulko.se>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org, Nhat Pham <nphamcs@...il.com>, Shakeel Butt
 <shakeel.butt@...ux.dev>, Johannes Weiner <hannes@...xchg.org>, Yosry Ahmed
 <yosry.ahmed@...ux.dev>, Minchan Kim <minchan@...nel.org>, Sergey
 Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH] mm/zblock: use vmalloc for page allocations

On 2025-05-02 12:01, Vitaly Wool wrote:
> From: Igor Belousov <igor.b@...dev.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@...dev.am>
> Signed-off-by: Vitaly Wool <vitaly.wool@...sulko.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

Thanks,
Igor