On 08/14/2012 12:36 AM, Nitin Gupta wrote: > On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote: >> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote: >>> This patchset promotes zram/zsmalloc from staging. >>> Both are very clean and zram is used by many embedded product >>> for a long time. >>> >>> [1-3] are patches not merged into linux-next yet but needed >>> it as base for [4-5] which promotes zsmalloc. >>> Greg, if you merged [1-3] already, skip them. >> >> I've applied 1-3 and now 4, but that's it, I can't apply the rest >> without getting acks from the -mm maintainers, sorry. Please work with >> them to get those acks, and then I will be glad to apply the rest (after >> you resend them of course...) >> > > On a second thought, I think zsmalloc should stay in drivers/block/zram > since zram is now the only user of zsmalloc since zcache and ramster are > moving to another allocator. The removal of zsmalloc from zcache has not been agreed upon yet. Dan _suggested_ removing zsmalloc as the persistent allocator for zcache in favor of zbud to solve "flaws" in zcache. However, zbud has large deficiencies. A zero-filled 4k page will compress with LZO to 103 bytes. zbud can only store two compressed pages in each memory pool page, resulting in 95% fragmentation (i.e. 95% of the memory pool page goes unused). While this might not be a typical case, it is the worst case and absolutely does happen. zbud's design also effectively limits the useful page compression to 50%. If pages are compressed beyond that, the added space savings is lost in memory pool fragmentation. For example, if two pages compress to 30% of their original size, those two pages take up 60% of the zbud memory pool page, and 40% is lost to fragmentation because zbud can't store anything in the remaining space. To say it another way, for every two page cache pages that cleancache stores in zcache, zbud _must_ allocate a memory pool page, regardless of how well those pages compress. This reduces the efficiency of the page cache reclaim mechanism by half. I have posted some work (zsmalloc shrinker interface, user registered alloc/free functions for the zsmalloc memory pool) that begins to make zsmalloc a suitable replacement for zbud, but that work was put on hold until the path out of staging was established. I'm hoping to continue this work once the code is in mainline. While zbud has deficiencies, it doesn't prevent zcache from having value as I have already demonstrated. However, replacing zsmalloc with zbud would step backward for the reasons mentioned above. I do not support the removal of zsmalloc from zcache. As such, I think the zsmalloc code should remain independent. Seth -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>