From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751574AbbCICVh (ORCPT ); Sun, 8 Mar 2015 22:21:37 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:36475 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751024AbbCICVg (ORCPT ); Sun, 8 Mar 2015 22:21:36 -0400 Date: Mon, 9 Mar 2015 11:21:27 +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: <20150309022127.GF15184@blaptop> 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> <20150309020717.GC794@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309020717.GC794@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 11:07:17AM +0900, Sergey Senozhatsky wrote: > 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. Thanks! > > > 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/io_stat > > s*printf( num_reads, num_writes, failed_reads, failed_writes, etc.) Some of it(ie, num_reads, num_writes) was duplicated with /dev/block/zramx/stat? I know /dev/block/zramx/stat doesn't work now and I didn't check why it doesn't work but I hope we make it work so remove duplicate stat, finally. :) > > zram/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. Sounds good so we could warn for 1 or 2 years if users are about to use old stat and finally removes deprecated stat. Please Cc util-linux zram-control peoples when you send patchset. > > -ss -- Kind regards, Minchan Kim