linux-kernel - Re: [PATCHv1 0/8] zram: introduce multi-handle entries

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: <20241119092059.GC2668855@google.com>
Date: Tue, 19 Nov 2024 18:20:59 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv1 0/8] zram: introduce multi-handle entries

On (24/11/19 16:20), Sergey Senozhatsky wrote:
> 	ZRAM_HUGE objects are incompressible and each takes a whole
> physical page on the zsmalloc side.  zsmalloc pool, naturally, has
> some internal memory fragmentation (within size-classes), so what
> we can do for ZRAM_HUGE objects is to split them into several
> smaller objects (2 at this point) and store those parts individually
> in regular size-classes (hence multi-handle entries). This, basically,
> lets us to use already allocated (but unused) zspages memory for
> ZRAM_HUGE objects, instead of unconditional allocation of 0-order
> page for each ZRAM_HUGE object.

Forgot to mention, this is still just "RFC".