linux-kernel - Re: [RFC PATCH 5/6] zsmalloc: introduce handle mapping API

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] [day] [month] [year] [list]

Message-ID: <5iotloij4kc6cjugszxh2bpalszwcptwkvqkwigbpehqql7m5q@kylewcf3d5ga>
Date: Wed, 29 Jan 2025 14:40:43 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Minchan Kim <minchan@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Nhat Pham <nphamcs@...il.com>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 5/6] zsmalloc: introduce handle mapping API

On (25/01/28 01:36), Yosry Ahmed wrote:
> zs_obj_read_start(.., buf)
> {
> 	if (contained in one page)
> 		return kmapped obj
> 	else
> 		memcpy to buf
> 		return buf
> }
> 
> zs_obj_read_end(.., buf)
> {
> 	if (container in one page)
> 		kunmap
> }

So it seems we can optimize things a little further by avoiding more
memcpy() calls.  Namely, for WO directions [on objects that span two
pages] the caller first memcpy() data to a provided temp buffer (per-CPU
buffer at this moment) and then during zs_unmap() memcpy() from that temp
buffer to physical pages that object spans accross.  We can skip this memcpy()
and instead write to physical pages straight from the compression buffer.

I'll post an updated series shortly.