Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Sangseok Lee <sangseok.lee@lge.com>,
	Chanho Min <chanho.min@lge.com>,
	Chan Gyun Jeong <chan.jeong@lge.com>
Subject: Re: [PATCH] mm: add NR_ZSMALLOC to vmstat
Date: Tue, 7 Jun 2016 10:43:40 +0900
Message-ID: <20160607014340.GB26230@bbox> (raw)
In-Reply-To: <20160603102432.GB586@swordfish>

Hi Sergey,

On Fri, Jun 03, 2016 at 07:24:32PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (06/03/16 17:23), Minchan Kim wrote:
> > On Fri, Jun 03, 2016 at 05:01:41PM +0900, Sergey Senozhatsky wrote:
> > > On (06/03/16 11:08), Minchan Kim wrote:
> > > > Now, zram is very popular for some of embedded world(e.g., TV, mobile
> > > > phone). On those system, zsmalloc consumed memory size is never trivial
> > > > (one of example from real product system, total memory: 800M, zsmalloc
> > > > consumed: 150M), so we have used this out of tree patch to monitor system
> > > > memory behavior via /proc/vmstat.
> > > > 
> > > > With zsmalloc in vmstat, it helps tracking down system behavior by
> > > > memory usage.
> > > 
> > > Hello,
> > > 
> > > may be use zsmalloc stats file instead? as far as I know, you keep
> > > zsmalloc stats enabled in production anyway.
> > 
> > It doesn't support per-zone stat which is important to show
> > the fragmentation of the zone, for exmaple.
> 
> Ah, I see.
> 
> *just an idea*
> 
> may be zbud and z3fold folks will be interested as well, so may

First motivation of stat came from fragmentation problem from zsmalloc
which caused by storing many thin zpages in a pageframe and across two
pageframes while zswap limits the limitation by design.

Second motivation is zsmalloc can allocate page from HIGH/movable zones
so I want to know how distribution zsmalloced pages is.
However, zbud doesn't.

Lastly, zswap is designed for short-lived with backed storage so I guess
it shouldn't be a problem.

http://marc.info/?l=linux-mm&m=136570894925571&w=2
http://marc.info/?l=linux-kernel&m=136571103026450&w=2

Quote from Seth
"
> Compaction - compaction would basically involve creating a virtual address
> space of sorts, which zsmalloc is capable of through its API with handles,
> not pointer. However, as Dan points out this requires a structure the maintain
> the mappings and adds to complexity. Additionally, the need for compaction
> diminishes as the allocations are short-lived with frontswap backends doing
> writeback and cleancache backends shrinking.

Of course I say this, but for zram, this can be important as the allocations
can't be moved out of memory and, therefore, are long lived. I was speaking
from the zswap perspective.
"


> be more generic name and define... um, my head doesn't work toay..
> ZALLOC... ZPOOLALLOC... hm.. I think you got the idea.

Having said that, generic name is better rather than zsmalloc. Thanks.
I want to use *zspage* which is term from the beginning of zprojects. :)

--
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>

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03  2:08 Minchan Kim
2016-06-03  8:01 ` Sergey Senozhatsky
2016-06-03  8:23   ` Minchan Kim
2016-06-03 10:24     ` Sergey Senozhatsky
2016-06-07  1:43       ` Minchan Kim [this message]
2016-06-09  1:40         ` Sergey Senozhatsky

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=20160607014340.GB26230@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chan.jeong@lge.com \
    --cc=chanho.min@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sangseok.lee@lge.com \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git