Recently, there was issue about zsmalloc fragmentation and
I got a report from Juneho that new fork failed although there
are plenty of free pages in the system.
His investigation revealed zram is one of the culprit to make
heavy fragmentation so there was no more contiguous 16K page
for pgd to fork in the ARM.
This patchset implement *basic* zsmalloc compaction support
and zram utilizes it so admin can do
"echo 1 > /sys/block/zram0/compact"
In my experiment(high compress ratio data with heavy swap in/out
on zram 8G swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
This patchset adds more logics in zsmalloc but when I tested
heavy swapin/out program, the regression is marginal because
most of overheads were caused by compress/decompress and
other MM reclaim stuff.
Minchan Kim (10):
zram: avoid calling of zram_meta_free under init_lock
zsmalloc: decouple handle and object
zsmalloc: implement reverse mapping
zsmalloc: factor out obj_[malloc|free]
zsmalloc: add status bit
zsmalloc: support compaction
zsmalloc: adjust ZS_ALMOST_FULL
zram: support compaction
zsmalloc: add fullness into stat
zsmalloc: record handle in page->private for huge object
Documentation/ABI/testing/sysfs-block-zram | 8 +
drivers/block/zram/zram_drv.c | 30 +-
drivers/block/zram/zram_drv.h | 1 +
include/linux/zsmalloc.h | 1 +
mm/zsmalloc.c | 1008 +++++++++++++++++++++-------
5 files changed, 786 insertions(+), 262 deletions(-)
--
1.9.3
--
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>