From: Minchan Kim <minchan@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Juneho Choi <juno.choi@lge.com>, Gunho Lee <gunho.lee@lge.com>,
Luigi Semenzato <semenzato@google.com>,
Dan Streetman <ddstreet@ieee.org>,
Seth Jennings <sjennings@variantweb.net>,
Nitin Gupta <ngupta@vflare.org>,
Jerome Marchand <jmarchan@redhat.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
opensource.ganesh@gmail.com, Minchan Kim <minchan@kernel.org>
Subject: [PATCH v2 0/7] zsmalloc: compaction support
Date: Wed, 4 Mar 2015 14:01:25 +0900 [thread overview]
Message-ID: <1425445292-29061-1-git-send-email-minchan@kernel.org> (raw)
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that 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.
2) non-movable pages
Other problem of zram now is that inherently, user want to use
zram as swap in small memory system so they use zRAM with CMA to
use memory efficiently. However, unfortunately, it doesn't work well
because zRAM cannot use CMA's movable pages unless it doesn't support
compaction. I got several reports about that OOM happened with
zram although there are lots of swap space and free space
in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit
memory usage and I sent a patchset(https://lkml.org/lkml/2014/9/21/148)
for VM to be harmonized with zram-swap to stop anonymous page reclaim
if zram consumed memory up to the limit although there are free space
on the swap. One problem for that direction is zram has no way to know
any hole in memory space zsmalloc allocated by internal fragmentation
so zram would regard swap is full although there are free space in
zsmalloc. For solving the issue, zram want to trigger compaction
of zsmalloc before it decides full or not.
This patchset is first step to support above issues. For that,
it adds indirect layer between handle and object location and
supports manual compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware
of zsmalloc compaction so that generic compaction will move
zsmalloced-pages automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with
heavy swap in/out on 8G zram-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
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but
when I tested heavy swapin/out program, the regression for
swapin/out speed is marginal because most of overheads were caused
by compress/decompress and other MM reclaim stuff.
* from v1
* remove rcu - suggested by Joonsoo
* iterating biggest size class - Seth
* add experiment data in description - Juneho
Minchan Kim (7):
zsmalloc: decouple handle and object
zsmalloc: factor out obj_[malloc|free]
zsmalloc: support compaction
zsmalloc: adjust ZS_ALMOST_FULL
zram: support compaction
zsmalloc: record handle in page->private for huge object
zsmalloc: add fullness into stat
Documentation/ABI/testing/sysfs-block-zram | 15 +
drivers/block/zram/zram_drv.c | 25 +
drivers/block/zram/zram_drv.h | 1 +
include/linux/zsmalloc.h | 1 +
mm/zsmalloc.c | 991 +++++++++++++++++++++--------
5 files changed, 777 insertions(+), 256 deletions(-)
--
1.9.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2015-03-04 5:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 5:01 Minchan Kim [this message]
2015-03-04 5:01 ` [PATCH v2 1/7] zsmalloc: decouple handle and object Minchan Kim
2015-03-04 5:07 ` Minchan Kim
2015-03-04 5:01 ` [PATCH v2 2/7] zsmalloc: factor out obj_[malloc|free] Minchan Kim
2015-03-04 5:01 ` [PATCH v2 3/7] zsmalloc: support compaction Minchan Kim
2015-03-05 5:18 ` Heesub Shin
2015-03-09 0:05 ` Minchan Kim
2015-03-04 5:01 ` [PATCH v2 4/7] zsmalloc: adjust ZS_ALMOST_FULL Minchan Kim
2015-03-04 5:01 ` [PATCH v2 5/7] zram: support compaction Minchan Kim
2015-03-04 5:01 ` [PATCH v2 6/7] zsmalloc: record handle in page->private for huge object Minchan Kim
2015-03-04 5:01 ` [PATCH v2 7/7] zsmalloc: add fullness into stat Minchan Kim
2015-03-04 22:02 ` Andrew Morton
2015-03-05 0:43 ` Minchan Kim
2015-03-05 0:56 ` Andrew Morton
2015-03-04 5:09 ` [PATCH v2 0/7] zsmalloc: compaction support Minchan Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1425445292-29061-1-git-send-email-minchan@kernel.org \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ddstreet@ieee.org \
--cc=gunho.lee@lge.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jmarchan@redhat.com \
--cc=juno.choi@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ngupta@vflare.org \
--cc=opensource.ganesh@gmail.com \
--cc=semenzato@google.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=sjennings@variantweb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).