9a001fc19c
This patch introduces z3fold, a special purpose allocator for storing compressed pages. It is designed to store up to three compressed pages per physical page. It is a ZBUD derivative which allows for higher compression ratio keeping the simplicity and determinism of its predecessor. This patch comes as a follow-up to the discussions at the Embedded Linux Conference in San-Diego related to the talk [1]. The outcome of these discussions was that it would be good to have a compressed page allocator as stable and deterministic as zbud with with higher compression ratio. To keep the determinism and simplicity, z3fold, just like zbud, always stores an integral number of compressed pages per page, but it can store up to 3 pages unlike zbud which can store at most 2. Therefore the compression ratio goes to around 2.6x while zbud's one is around 1.7x. The patch is based on the latest linux.git tree. This version has been updated after testing on various simulators (e.g. ARM Versatile Express, MIPS Malta, x86_64/Haswell) and basing on comments from Dan Streetman [3]. [1] https://openiotelc2016.sched.org/event/6DAC/swapping-and-embedded-compression-relieves-the-pressure-vitaly-wool-softprise-consulting-ou [2] https://lkml.org/lkml/2016/4/21/799 [3] https://lkml.org/lkml/2016/5/4/852 Link: http://lkml.kernel.org/r/20160509151753.ec3f9fda3c9898d31ff52a32@gmail.com Signed-off-by: Vitaly Wool <vitalywool@gmail.com> Cc: Seth Jennings <sjenning@redhat.com> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
27 lines
1.2 KiB
Plaintext
27 lines
1.2 KiB
Plaintext
z3fold
|
|
------
|
|
|
|
z3fold is a special purpose allocator for storing compressed pages.
|
|
It is designed to store up to three compressed pages per physical page.
|
|
It is a zbud derivative which allows for higher compression
|
|
ratio keeping the simplicity and determinism of its predecessor.
|
|
|
|
The main differences between z3fold and zbud are:
|
|
* unlike zbud, z3fold allows for up to PAGE_SIZE allocations
|
|
* z3fold can hold up to 3 compressed pages in its page
|
|
* z3fold doesn't export any API itself and is thus intended to be used
|
|
via the zpool API.
|
|
|
|
To keep the determinism and simplicity, z3fold, just like zbud, always
|
|
stores an integral number of compressed pages per page, but it can store
|
|
up to 3 pages unlike zbud which can store at most 2. Therefore the
|
|
compression ratio goes to around 2.7x while zbud's one is around 1.7x.
|
|
|
|
Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not
|
|
return a dereferenceable pointer. Instead, it returns an unsigned long
|
|
handle which encodes actual location of the allocated object.
|
|
|
|
Keeping effective compression ratio close to zsmalloc's, z3fold doesn't
|
|
depend on MMU enabled and provides more predictable reclaim behavior
|
|
which makes it a better fit for small and response-critical systems.
|