mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-05 01:54:09 +08:00
ee65728e10
so it will be consistent with code mm directory and with Documentation/admin-guide/mm and won't be confused with virtual machines. Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Suggested-by: Matthew Wilcox <willy@infradead.org> Tested-by: Ira Weiny <ira.weiny@intel.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Wu XiangCheng <bobwxc@email.cn>
31 lines
1.2 KiB
ReStructuredText
31 lines
1.2 KiB
ReStructuredText
.. _z3fold:
|
|
|
|
======
|
|
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.
|