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: <20250129131723.3761142-1-chao.shun.cheng.tw@gmail.com>
Date: Wed, 29 Jan 2025 21:17:23 +0800
From: Kenny Cheng <chao.shun.cheng.tw@...il.com>
To: senozhatsky@...omium.org
Cc: akpm@...ux-foundation.org,
	c.s.cheng@...ltek.com,
	chao.shun.cheng.tw@...il.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	minchan@...nel.org,
	yosry.ahmed@...ux.dev
Subject: Re: [PATCH v2] zsmalloc: Fix address alignment in zspage for performance improvement

> Hmm, I don't know.  If we change zsmalloc to make some H/W happy, how
> do we make sure that something that is good for Realtek is not "bad"
> for some other H/W?

No, this patch would not have any impact on other HW. This patch only
changes the position of "link struct" from head to tail in an object.

Example:
A 32-bit system, using a zspage with a class size of 32 bytes and a 4K
page system.

In this case, the address is obtained from zs_map_object if zsmalloc is
used with this zspage.

Without this patch: The address is aligned to 4 bytes.
The alignment size is always the same as the size of the "link struct."
With this patch: The address is aligned to 32 bytes.
The alignment size can be controlled by the class size.

For the SW zram algorithm, this patch has no effect. For the HW zram
algorithm, which requires 4-byte alignment, this patch has no effect
either.

However, for the HW zram algorithm that requires more than 4-byte
alignment, this patch can improve zram performance if the class size is
aligned with the required size.

> I'm very unsure about having "vendor-specific" (by the way, is that
> out-of-tree compression/decompression driver?) changes in zsmalloc.

Yes, it is an out-of-tree driver. It is common compression/decompression
algorithm such as lz4, zstd, and so on. The only difference is that the
implementation is based on in-house designed HW.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ