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: <83CB359A-955E-48B6-B0D9-DD4F2E1146D4@konsulko.se>
Date: Sat, 3 May 2025 20:46:07 +0200
From: Vitaly Wool <vitaly.wool@...sulko.se>
To: Igor Belousov <igor.b@...dev.am>
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 May 2, 2025, at 10:07 AM, Igor Belousov <igor.b@...dev.am> wrote:
> 
> 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

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.

~Vitaly