1*4882a593Smuzhiyun.. _z3fold: 2*4882a593Smuzhiyun 3*4882a593Smuzhiyun====== 4*4882a593Smuzhiyunz3fold 5*4882a593Smuzhiyun====== 6*4882a593Smuzhiyun 7*4882a593Smuzhiyunz3fold is a special purpose allocator for storing compressed pages. 8*4882a593SmuzhiyunIt is designed to store up to three compressed pages per physical page. 9*4882a593SmuzhiyunIt is a zbud derivative which allows for higher compression 10*4882a593Smuzhiyunratio keeping the simplicity and determinism of its predecessor. 11*4882a593Smuzhiyun 12*4882a593SmuzhiyunThe main differences between z3fold and zbud are: 13*4882a593Smuzhiyun 14*4882a593Smuzhiyun* unlike zbud, z3fold allows for up to PAGE_SIZE allocations 15*4882a593Smuzhiyun* z3fold can hold up to 3 compressed pages in its page 16*4882a593Smuzhiyun* z3fold doesn't export any API itself and is thus intended to be used 17*4882a593Smuzhiyun via the zpool API. 18*4882a593Smuzhiyun 19*4882a593SmuzhiyunTo keep the determinism and simplicity, z3fold, just like zbud, always 20*4882a593Smuzhiyunstores an integral number of compressed pages per page, but it can store 21*4882a593Smuzhiyunup to 3 pages unlike zbud which can store at most 2. Therefore the 22*4882a593Smuzhiyuncompression ratio goes to around 2.7x while zbud's one is around 1.7x. 23*4882a593Smuzhiyun 24*4882a593SmuzhiyunUnlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not 25*4882a593Smuzhiyunreturn a dereferenceable pointer. Instead, it returns an unsigned long 26*4882a593Smuzhiyunhandle which encodes actual location of the allocated object. 27*4882a593Smuzhiyun 28*4882a593SmuzhiyunKeeping effective compression ratio close to zsmalloc's, z3fold doesn't 29*4882a593Smuzhiyundepend on MMU enabled and provides more predictable reclaim behavior 30*4882a593Smuzhiyunwhich makes it a better fit for small and response-critical systems. 31