Hi Johannes, On Tue, Nov 02, 2021 at 11:06:17AM -0400, Johannes Weiner wrote: > Hi Minchan, > > Sorry about the delay, I'm just now getting back to these patches. > > On Mon, Aug 30, 2021 at 11:49:59AM -0700, Minchan Kim wrote: > > Hi Johannes, > > > > On Thu, Aug 19, 2021 at 03:55:33PM -0400, Johannes Weiner wrote: > > > Currently it requires poking at debugfs to figure out the size of the > > > zswap cache size on a host. There are no counters for reads and writes > > > against the cache. This makes it difficult to understand behavior on > > > production systems. > > > > > > Print zswap memory consumption in /proc/meminfo, count zswapouts and > > > zswapins in /proc/vmstat. > > > > > > Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx> > > > --- > > > fs/proc/meminfo.c | 4 ++++ > > > include/linux/swap.h | 4 ++++ > > > include/linux/vm_event_item.h | 4 ++++ > > > mm/vmstat.c | 4 ++++ > > > mm/zswap.c | 11 +++++------ > > > 5 files changed, 21 insertions(+), 6 deletions(-) > > > > > > diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c > > > index 6fa761c9cc78..2dc474940691 100644 > > > --- a/fs/proc/meminfo.c > > > +++ b/fs/proc/meminfo.c > > > @@ -86,6 +86,10 @@ static int meminfo_proc_show(struct seq_file *m, void *v) > > > > > > show_val_kb(m, "SwapTotal: ", i.totalswap); > > > show_val_kb(m, "SwapFree: ", i.freeswap); > > > +#ifdef CONFIG_ZSWAP > > > + seq_printf(m, "Zswap: %8lu kB\n", > > > + (unsigned long)(zswap_pool_total_size >> 10)); > > > > Since we have zram as well as zswap, it would be great if > > we can abstract both at once without introducing another > > "Zram: " stuff in meminfo. A note: zram can support fs based on > > on zram blk device as well as swap. Thus, term would be better > > to say "compressed" rather than "swap". > > > > How about this? > > > > "Compressed: xx kB" > > Wouldn't it make more sense to keep separate counters? Zswap and zram > are quite different from each other. > > From an MM perspective, zram is an opaque storage backend. zswap OTOH > is an explicit MM cache stage which may in the future make different > decisions than zram, be integrated into vmscan's LRU hierarchy > etc. And in theory, you could put zswap with fast compression in front > of a zram device with denser compression, right? My view is the the allocators aims to store compressed memory. Likewise slab allocator, we could use the allocator any places and display the total memory usage from the allocator in meminfo instead of each subsystem and look at slabinfo if we need further break down. I think it could work for this case, too. > > I agree zram should probably also have memory counters, but I think it > makes sense to recognize zswap as a unique MM layer. Under your view, I think it would introduce Zram-swap, Zram-block as well as Zswap. If folks think it's better idea, I am fine and happy to post a patch to merge it along with this patch.
