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

Message-ID: <Z5kSILla_8WXN1Pw@google.com>
Date: Tue, 28 Jan 2025 17:21:36 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: 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 Tue, Jan 28, 2025 at 06:38:35PM +0900, Sergey Senozhatsky wrote:
> On (25/01/28 14:29), Sergey Senozhatsky wrote:
> > Maybe copy-in is just an okay thing to do.  Let me try to measure.
> 
> Naaah, not really okay.  On our memory-pressure test (4GB device, 4
> CPUs) that kmap_local thingy appears to save approx 6GB of memcpy().
> 
> CPY stats: 734954 1102903168 4926116 6566654656
> 
> There were 734954 cases when we memcpy() [object spans two pages] with
> accumulated size of 1102903168 bytes, and 4926116 cases when we took
> a shortcut via kmap_local and avoided memcpy(), with accumulated size
> of 6566654656 bytes.
> 
> In both cases I counted only RO direction for map, and WO direction
> for unmap.

Yeah seems like the optimization is effective, at least on that
workload, unless the memcpy() is cheap and avoiding it is not buying as
much (do you know if that's the case?).

Anyway, we can keep the optimization and zswap could start making use of
it if zsmalloc becomes preemtible, so that's still a win.