From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932079AbbCIBrN (ORCPT ); Sun, 8 Mar 2015 21:47:13 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:43792 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751170AbbCIBrL (ORCPT ); Sun, 8 Mar 2015 21:47:11 -0400 Date: Mon, 9 Mar 2015 10:47:02 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: akpm@linux-foundation.org, ddstreet@ieee.org, gunho.lee@lge.com, iamjoonsoo.kim@lge.com, jmarchan@redhat.com, juno.choi@lge.com, mel@csn.ul.ie, ngupta@vflare.org, semenzato@google.com, sergey.senozhatsky@gmail.com, sjennings@variantweb.net, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: + zram-support-compaction.patch added to -mm tree Message-ID: <20150309014702.GE15184@blaptop> References: <54f780fc.3sOWZKr7rufmI85r%akpm@linux-foundation.org> <20150305052941.GK14927@swordfish> <20150309004859.GB15184@blaptop> <20150309005718.GA794@swordfish> <20150309010522.GD15184@blaptop> <20150309012728.GB794@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309012728.GB794@swordfish> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 09, 2015 at 10:27:28AM +0900, Sergey Senozhatsky wrote: > On (03/09/15 10:05), Minchan Kim wrote: > > > well, to be fair, compaction is a zsmalloc internal. zram has nothing to do with > > > it. > > > > > > but do we we even need this stat? it seems that > > > > > > mem_total_used (before compaction) - mem_total_user (after comapction) > > > > > > will give user an idea on how much memory was compacted. > > > > It's not enough. What I want to know is compaction efficiency per client of > > zsmalloc(ie, zram). > > > > so what a typical user can do with this information? isn't it an entirely > debug info that makes some hidden sense only to developers? Absolutely true. > > if you insist on exporting this as a zram stat for everyone how obout > starting to move away from per-stat RO sysfs attrs. it seems that we have > uncomfortably a lot of sysfs attrs, and that doesn't make life easier in > user space. for example, block devices have /sys/block/.../stat file: > > /sys/block/sda$ cat stat > 45931 59 2075686 289906 55768 9229 1967800 318033 0 193583 607806 > > and there are no num_reads, num_writes, num_failed_reads, num_failed_writes, > etc., etc. per-stat sysfs attrs force user-space to do lots of syscalls: > open(), read(), close() with error control on every step; for every stat. I absoulte agree with you and I really wanted to tidy it up but was no time. Sergey, Could you contribute? If you have no time, I will do by myself but it would be low priority now. > > so how about introducing zram/malloc_stats (or any similar name) and > provide compaction and all future allocator related stats there > (via s*printf("%d %d %d", ....)) ? > > -ss > > > IOW, (how many of freed pages / how many of objects) per > > zs_compact. > > > > > > > > -ss > > > > > > > That's why it is on debugfs. If we add the stat into zsmalloc, we should turn on debugfs > > > > and CONFIG_ZSMALLOC_STAT to see *a* stat. Even, CONFIG_ZSMALLOC_STAT will add > > > > unncessary overheads to account another stats fo zsmalloc internals. > > > > > > > > As well, if we add auto-compacion like stuff in zsmalloc(ie, it will trigger > > > > by itself if fragmention is over to predefined theshold), the stat will > > > > accumulate stat while someone want to see snapshot compaction effiecieny > > > > of the moment. > > > > > > > > So, I want to keep it in zram now. > > > > > > > > -- > > > > Kind regards, > > > > Minchan Kim > > > > > > > > -- > > Kind regards, > > Minchan Kim > > -- Kind regards, Minchan Kim