Hello, RFC ->huge classes are evil, and zsmalloc knows the watermark after which classes are considered to be ->huge -- every object stored consumes the entire zspage (which consist of a single order-0 page). zram, however, has its own statically defined watermark for `bad' compression and stores every object larger than this watermark as a PAGE_SIZE, object, IOW, to a ->huge class, this results in increased memory consumption and memory wastage. And zram's 'bad' watermark is much lower than zsmalloc. Apart from that, 'bad' compressions are not so rare, on some of my tests 41% of writes result in 'bad' compressions. This patch set inverts this 'huge class watermark' enforcement, it's zsmalloc that knows better, not zram. I did a number of tests (see 0003 commit message) and memory savings were around 36MB and 51MB (depending on zsmalloc configuration). I also copied a linux-next directory (with object files, du -sh 2.5G) and (ZS_MAX_PAGES_PER_ZSPAGE=5) memory saving were around 17-20MB. Sergey Senozhatsky (3): mm/zsmalloc: introduce zs_get_huge_class_size_watermark() zram: use zs_get_huge_class_size_watermark() mm/zsmalloc: change ZS_MAX_PAGES_PER_ZSPAGE drivers/block/zram/zram_drv.c | 2 +- drivers/block/zram/zram_drv.h | 6 ------ include/linux/zsmalloc.h | 2 ++ mm/zsmalloc.c | 21 +++++++++++++++++---- 4 files changed, 20 insertions(+), 11 deletions(-) -- 2.7.1 -- 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>