Date:	Thu, 4 Dec 2014 16:20:53 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	"박승호/책임연구원/SW Platform(연)AOT팀(seungho1.park@....com)" 
	<seungho1.park@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Nitin Gupta <ngupta@...are.org>,
	Dan Streetman <ddstreet@...e.org>,
	Seth Jennings <sjennings@...iantweb.net>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Luigi Semenzato <semenzato@...gle.com>,
	Jerome Marchand <jmarchan@...hat.com>, juno.choi@....com
Subject: Re: [RFC 0/6] zsmalloc support compaction

Hey Seungho,

On Thu, Dec 04, 2014 at 03:49:21PM +0900, "박승호/책임연구원/SW Platform(연)AOT팀(seungho1.park@....com)" wrote:
> Hi, Minchan.
> 
> I have a question.
> The problem mentioned can't be resolved with compaction?
> Is there any reason that zsmalloc pages can't be moved by compaction
> operation in direct reclaim?

Currently, zsmalloc doesn't request movable page to page allocator
since compaction is not aware of zram pages(ie, PageZram(page)).
IOW, compaction cannot migrate zram pages at the moment.
As I described, it's final destination we should go but I think
we need more thinking to generalize such special pages handling
(ex, balloon, zswap, zram and so on for future) in compaction logic.

Now, I want to merge basic primitive functions in zsmalloc to
support zspage migration, which will be used as basic utility functions
for supporting compaction-aware zspage migration.

In addition, even we need manual opeartion logic to trigger
compaction for zsmalloc like /proc/sys/vm/compact_memory.

> 
> 2014-12-02 오전 11:49에 Minchan Kim 이(가) 쓴 글:
> >Recently, there was issue about zsmalloc fragmentation and
> >I got a report from Juno 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"
> >
> >Actually, ideal is that mm migrate code is aware of zram pages and
> >migrate them out automatically without admin's manual opeartion
> >when system is out of contiguous page. Howver, we need more thinking
> >before adding more hooks to migrate.c. Even though we implement it,
> >we need manual trigger mode, too so I hope we could enhance
> >zram migration stuff based on this primitive functions in future.
> >
> >I just tested it on only x86 so need more testing on other arches.
> >Additionally, I should have a number for zsmalloc regression
> >caused by indirect layering. Unfortunately, I don't have any
> >ARM test machine on my desk. I will get it soon and test it.
> >Anyway, before further work, I'd like to hear opinion.
> >
> >Pathset is based on v3.18-rc6-mmotm-2014-11-26-15-45.
> >
> >Thanks.
> >
> >Minchan Kim (6):
> >   zsmalloc: expand size class to support sizeof(unsigned long)
> >   zsmalloc: add indrection layer to decouple handle from object
> >   zsmalloc: implement reverse mapping
> >   zsmalloc: encode alloced mark in handle object
> >   zsmalloc: support compaction
> >   zram: support compaction
> >
> >  drivers/block/zram/zram_drv.c |  24 ++
> >  drivers/block/zram/zram_drv.h |   1 +
> >  include/linux/zsmalloc.h      |   1 +
> >  mm/zsmalloc.c                 | 596 +++++++++++++++++++++++++++++++++++++-----
> >  4 files changed, 552 insertions(+), 70 deletions(-)
> >
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists