[<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