From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932121AbbCICHP (ORCPT <rfc822;w@1wt.eu>);
	Sun, 8 Mar 2015 22:07:15 -0400
Received: from mail-pa0-f47.google.com ([209.85.220.47]:42877 "EHLO
	mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753219AbbCICHM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 8 Mar 2015 22:07:12 -0400
Date: Mon, 9 Mar 2015 11:07:17 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        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: <20150309020717.GC794@swordfish>
References: <54f780fc.3sOWZKr7rufmI85r%akpm@linux-foundation.org>
 <20150305052941.GK14927@swordfish>
 <20150309004859.GB15184@blaptop>
 <20150309005718.GA794@swordfish>
 <20150309010522.GD15184@blaptop>
 <20150309012728.GB794@swordfish>
 <20150309014702.GE15184@blaptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150309014702.GE15184@blaptop>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (03/09/15 10:47), Minchan Kim wrote:
> > > 
> > > 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.

sure. I can handle it.


I was thinking for some time already about splitting stats that we
export in two categories and, thus, two files: IO_stats and MM_stats.

zram<id>/io_stat

s*printf( num_reads, num_writes, failed_reads, failed_writes, etc.)

zram<id>/mm_stat
s*printf( orig_data_size, compr_data_size, mem_used_total, num_migrated, etc.)



so hoprefully in several years we can entirely remove ZRAM_ATTR_RO functions.
probably, first moving them under #ifdef CONFIG_OLD_ZRAM_STATS at some point
in the future.

	-ss