28.11.2022 23:01, Johannes Weiner пишет:
On Fri, Nov 04, 2022 at 11:58:56AM +0300, ananda wrote:From: Ananda <a.badmaev@xxxxxxxxxxxx> Zblock stores integer number of compressed objects per zblock block.What does that mean?
The general idea is to store an integer number of compressed pages in a fixed-size storage unit. In case of zbud and z3fold single pages act as this storage unit. In zblock, storage units can consist of several pages (page order 0, 1, 2 or 3), but still their size is set at compile time and does not change further.
These blocks consist of several physical pages (1/2/4/8) and are arranged in linked lists. The range from 0 to PAGE_SIZE is divided into the number of intervals corresponding to the number of lists and each list only operates objects of size from its interval. Thus the block lists are isolated from each other, which makes it possible to simultaneously perform actions with several objects from different lists.This was benchmarked not long ago in the context of zsmalloc, and it didn't seem to matter too much in real world applications: https://lore.kernel.org/linux-mm/20221107213114.916231-1-nphamcs@xxxxxxxxx/ Do you have situations where this matters?
It seems that in real applications, compression ratio mainly matters. According to my estimates, speed of allocator operations does not particularly contribute to overall performance compared to compression time.
Blocks make it possible to densely arrange objects of various sizes resulting in low internal fragmentation. Also this allocator tries to fill incomplete blocks instead of adding new ones thus in many cases providing a compression ratio substantially higher than z3fold and zbud.How does it compare to zsmalloc?
In general case: Zsmalloc > zsblock > z3fold > zbud
Zblock does not require MMU and also is superior to zsmalloc with regard to the worst execution times, thus allowing for better response time and real-time characteristics of the whole system.zsmalloc has depends on MMU, but which parts actually require it? It has its own handle indirection and can migrate objects around and replace backing pages without any virtual memory tricks. There is the kmap stuff of course, because it supports highmem backing pages, but that isn't relevant on NOMMU either. Also can you please elaborate on the worst execution time?
There is an opinion that use of zsmalloc can lead to an increase in response time. And zblock should have better real-time metrics.
My first impression is that this looks awfully close to zsmalloc, with a couple fewer features and somewhat more static design choices. It's in that sense reminiscent of the slob allocator, which we're in the process of removing, because 3 slab allocators is a pain to maintain. This would be the 4th zswap allocator, and it's not clear that it's drastically outperforming or doing something that isn't possible in one of the existing ones.
Initially there was an attempt to combine advantages of zbud and zsmalloc to obtain a fairly simple and fast allocator but with a compression ratio closer to zsmalloc.
