| .. _zsmalloc: | 
|   | 
| ======== | 
| zsmalloc | 
| ======== | 
|   | 
| This allocator is designed for use with zram. Thus, the allocator is | 
| supposed to work well under low memory conditions. In particular, it | 
| never attempts higher order page allocation which is very likely to | 
| fail under memory pressure. On the other hand, if we just use single | 
| (0-order) pages, it would suffer from very high fragmentation -- | 
| any object of size PAGE_SIZE/2 or larger would occupy an entire page. | 
| This was one of the major issues with its predecessor (xvmalloc). | 
|   | 
| To overcome these issues, zsmalloc allocates a bunch of 0-order pages | 
| and links them together using various 'struct page' fields. These linked | 
| pages act as a single higher-order page i.e. an object can span 0-order | 
| page boundaries. The code refers to these linked pages as a single entity | 
| called zspage. | 
|   | 
| For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE | 
| since this satisfies the requirements of all its current users (in the | 
| worst case, page is incompressible and is thus stored "as-is" i.e. in | 
| uncompressed form). For allocation requests larger than this size, failure | 
| is returned (see zs_malloc). | 
|   | 
| Additionally, zs_malloc() does not return a dereferenceable pointer. | 
| Instead, it returns an opaque handle (unsigned long) which encodes actual | 
| location of the allocated object. The reason for this indirection is that | 
| zsmalloc does not keep zspages permanently mapped since that would cause | 
| issues on 32-bit systems where the VA region for kernel space mappings | 
| is very small. So, before using the allocating memory, the object has to | 
| be mapped using zs_map_object() to get a usable pointer and subsequently | 
| unmapped using zs_unmap_object(). | 
|   | 
| stat | 
| ==== | 
|   | 
| With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via | 
| ``/sys/kernel/debug/zsmalloc/<user name>``. Here is a sample of stat output:: | 
|   | 
|  # cat /sys/kernel/debug/zsmalloc/zram0/classes | 
|   | 
|  class  size almost_full almost_empty obj_allocated   obj_used pages_used pages_per_zspage | 
|     ... | 
|     ... | 
|      9   176           0            1           186        129          8                4 | 
|     10   192           1            0          2880       2872        135                3 | 
|     11   208           0            1           819        795         42                2 | 
|     12   224           0            1           219        159         12                4 | 
|     ... | 
|     ... | 
|   | 
|   | 
| class | 
|     index | 
| size | 
|     object size zspage stores | 
| almost_empty | 
|     the number of ZS_ALMOST_EMPTY zspages(see below) | 
| almost_full | 
|     the number of ZS_ALMOST_FULL zspages(see below) | 
| obj_allocated | 
|     the number of objects allocated | 
| obj_used | 
|     the number of objects allocated to the user | 
| pages_used | 
|     the number of pages allocated for the class | 
| pages_per_zspage | 
|     the number of 0-order pages to make a zspage | 
|   | 
| We assign a zspage to ZS_ALMOST_EMPTY fullness group when n <= N / f, where | 
|   | 
| * n = number of allocated objects | 
| * N = total number of objects zspage can store | 
| * f = fullness_threshold_frac(ie, 4 at the moment) | 
|   | 
| Similarly, we assign zspage to: | 
|   | 
| * ZS_ALMOST_FULL  when n > N / f | 
| * ZS_EMPTY        when n == 0 | 
| * ZS_FULL         when n == N |