LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org> To: Minchan Kim <minchan@kernel.org> Cc: 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: Mon, 9 Apr 2018 10:03:45 +0200 [thread overview] Message-ID: <20180409080345.GC18095@kroah.com> (raw) In-Reply-To: <20180409055435.135695-5-minchan@kernel.org> 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. > + 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?) > +#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>
next prev parent reply other threads:[~2018-04-09 8:03 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 [this message] 2018-04-09 22:39 ` Minchan Kim 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=20180409080345.GC18095@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=akpm@linux-foundation.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: linkBe 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).