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