LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [PATCH v3 4/4] zram: introduce zram memory tracking
Date: Tue, 10 Apr 2018 07:39:36 +0900	[thread overview]
Message-ID: <20180410073936.a5de18504dd27e317474d197@gmail.com> (raw)
In-Reply-To: <20180409080345.GC18095@kroah.com>

On Mon, 9 Apr 2018 10:03:45 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Mon, Apr 09, 2018 at 02:54:35PM +0900, Minchan Kim wrote:
> > zRam as swap is useful for small memory device. However, swap means
> > those pages on zram are mostly cold pages due to VM's LRU algorithm.
> > Especially, once init data for application are touched for launching,
> > they tend to be not accessed any more and finally swapped out.
> > zRAM can store such cold pages as compressed form but it's pointless
> > to keep in memory. Better idea is app developers free them directly
> > rather than remaining them on heap.
> > 
> > This patch tell us last access time of each block of zram via
> > "cat /sys/kernel/debug/zram/zram0/block_state".
> > 
> > The output is as follows,
> >       300    75.033841 .wh
> >       301    63.806904 s..
> >       302    63.806919 ..h
> > 
> > First column is zram's block index and 3rh one represents symbol
> > (s: same page w: written page to backing store h: huge page) of the
> > block state. Second column represents usec time unit of the block
> > was last accessed. So above example means the 300th block is accessed
> > at 75.033851 second and it was huge so it was written to the backing
> > store.
> > 
> > Admin can leverage this information to catch cold|incompressible pages
> > of process with *pagemap* once part of heaps are swapped out.
> > 
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> >  Documentation/blockdev/zram.txt |  24 ++++++
> >  drivers/block/zram/Kconfig      |   9 +++
> >  drivers/block/zram/zram_drv.c   | 139 +++++++++++++++++++++++++++++---
> >  drivers/block/zram/zram_drv.h   |   5 ++
> >  4 files changed, 166 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
> > index 78db38d02bc9..45509c7d5716 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -243,5 +243,29 @@ to backing storage rather than keeping it in memory.
> >  User should set up backing device via /sys/block/zramX/backing_dev
> >  before disksize setting.
> >  
> > += memory tracking
> > +
> > +With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
> > +zram block. It could be useful to catch cold or incompressible
> > +pages of the proess with*pagemap.
> > +If you enable the feature, you could see block state via
> > +/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
> > +
> > +	  300    75.033841 .wh
> > +	  301    63.806904 s..
> > +	  302    63.806919 ..h
> > +
> > +First column is zram's block index.
> > +Second column is access time.
> > +Third column is state of the block.
> > +(s: same page
> > +w: written page to backing store
> > +h: huge page)
> > +
> > +First line of above example says 300th block is accessed at 75.033841sec
> > +and the block's state is huge so it is written back to the backing
> > +storage. It's a debugging feature so anyone shouldn't rely on it to work
> > +properly.
> > +
> >  Nitin Gupta
> >  ngupta@vflare.org
> > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> > index ac3a31d433b2..efe60c82d8ec 100644
> > --- a/drivers/block/zram/Kconfig
> > +++ b/drivers/block/zram/Kconfig
> > @@ -26,3 +26,12 @@ config ZRAM_WRITEBACK
> >  	 /sys/block/zramX/backing_dev.
> >  
> >  	 See zram.txt for more infomration.
> > +
> > +config ZRAM_MEMORY_TRACKING
> > +	bool "Tracking zram block status"
> > +	depends on ZRAM
> > +	select DEBUG_FS
> 
> Select?  Shouldn't you depend on this instead?  Selecting is a pain to
> try to track down what is keeping an option enabled.

Okay, I will modify.

> 
> > +	help
> > +	  With this feature, admin can track the state of allocated block
> > +	  of zRAM. Admin could see the information via
> > +	  /sys/kernel/debug/zram/zramX/block_state.
> 
> A short note here as to where to find the documentation for what that
> info is (i.e. in the file you wrote above?)

Yub. Will change.

> 
> > +#else
> > +static void zram_debugfs_create(void) {};
> > +static void zram_debugfs_destroy(void) {};
> > +static void zram_accessed(struct zram *zram, u32 index) {};
> > +static void zram_reset_access(struct zram *zram, u32 index) {};
> > +static void zram_debugfs_register(struct zram *zram) {};
> > +static void zram_debugfs_unregister(struct zram *zram) {};
> > +#endif
> 
> Much nicer, thanks!
> 
> The above was only very minor nits, no need to change anything if you
> don't want to.
> 
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I will wait a few days for getting review from Sergey and resend it with
fix.
Thanks for the review, Greg.

  reply	other threads:[~2018-04-09 22:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  5:54 [PATCH v3 0/4] zram memory tracking Minchan Kim
2018-04-09  5:54 ` [PATCH v3 1/4] zram: correct flag name of ZRAM_ACCESS Minchan Kim
2018-04-09  5:54 ` [PATCH v3 2/4] zram: mark incompressible page as ZRAM_HUGE Minchan Kim
2018-04-09  5:54 ` [PATCH v3 3/4] zram: record accessed second Minchan Kim
2018-04-09  5:54 ` [PATCH v3 4/4] zram: introduce zram memory tracking Minchan Kim
2018-04-09  8:03   ` Greg KH
2018-04-09 22:39     ` Minchan Kim [this message]
2018-04-10  0:03   ` Sergey Senozhatsky
2018-04-10  0:41     ` Sergey Senozhatsky
2018-04-10  6:22       ` Minchan Kim
2018-04-10  6:22     ` 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=20180410073936.a5de18504dd27e317474d197@gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky.work@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
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).