lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 15 Apr 2018 21:17:45 -0700 From: Randy Dunlap <rdunlap@...radead.org> To: Minchan Kim <minchan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org> Cc: LKML <linux-kernel@...r.kernel.org>, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Re: [PATCH v4 4/4] zram: introduce zram memory tracking On 04/15/2018 08:31 PM, 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. > > Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org> > Signed-off-by: Minchan Kim <minchan@...nel.org> > --- > Documentation/blockdev/zram.txt | 24 ++++++ > drivers/block/zram/Kconfig | 10 +++ > drivers/block/zram/zram_drv.c | 140 +++++++++++++++++++++++++++++--- > drivers/block/zram/zram_drv.h | 5 ++ > 4 files changed, 168 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. ? process > +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@...are.org > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig > index ac3a31d433b2..01090338fb47 100644 > --- a/drivers/block/zram/Kconfig > +++ b/drivers/block/zram/Kconfig > @@ -26,3 +26,13 @@ config ZRAM_WRITEBACK > /sys/block/zramX/backing_dev. > > See zram.txt for more infomration. > + > +config ZRAM_MEMORY_TRACKING > + bool "Tracking zram block status" bool "Track zram block status" although sometimes it is zRam or zRAM. > + depends on ZRAM && DEBUG_FS > + help > + With this feature, admin can track the state of allocated block blocks > + of zRAM. Admin could see the information via > + /sys/kernel/debug/zram/zramX/block_state. > + > + See zram.txt for more information. See Documentation/blockdev/zram.txt for more information. -- ~Randy
Powered by blists - more mailing lists