From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752181AbcECGvi (ORCPT ); Tue, 3 May 2016 02:51:38 -0400 Received: from mail-pa0-f67.google.com ([209.85.220.67]:34485 "EHLO mail-pa0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750837AbcECGvg (ORCPT ); Tue, 3 May 2016 02:51:36 -0400 Date: Tue, 3 May 2016 15:53:10 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] zram: user per-cpu compression streams Message-ID: <20160503065310.GD25545@swordfish> References: <20160502062311.GB6077@bbox> <20160502072508.GA1811@swordfish> <20160502082822.GC6077@bbox> <20160502092157.GA21764@swordfish> <20160503014018.GB2272@bbox> <20160503015333.GA9987@swordfish> <20160503022046.GB3642@bbox> <20160503023001.GB9987@swordfish> <20160503042902.GA25545@swordfish> <20160503050348.GA17316@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160503050348.GA17316@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (05/03/16 14:03), Minchan Kim wrote: > > will io_stat node work for you? > > Firstly, I thought io_stat would be better. However, on second thought, > I want to withdraw. > > I think io_stat should go away. > > failed_read > failed_write > invalid_io > > I think Above things are really unneeded. If something is fail, upper > class on top of zram, for example, FSes or Swap should emit the warning. > So, I don't think we need to maintain it in zram layer. > > notify_free > > It's kins of discard command for the point of block device so I think > general block should take care of it like read and write. If block will > do it, remained thing about notify_free is only zram_slot_free_notify > so I think we can move it from io_stat to mm_stat because it's related > to memory, not block I/O. > > With hoping with above things, I suggest let's not add anything to > io_stat any more from now on and let's remove it sometime. > Instead of it, let's add new dup stat. > > What do you think about it? I agree and it's true that we export a number of senseless and useless stats (well, to most of the users). what's your plan regarding the num_recompress file? is it guaranteed to go away once we convince ourselves that per-cpu streams are fine (1 or 2 years later) or will it stay? if it's 100% 'temporal' then _probably_ we can instead add a per-device /sys/.../zramID/debug_file (or similar name), document it as "IT WILL NEVER BE DOCUMENTED, IT WILL NEVER BE STABLE, DON'T EVER USE IT" and export there anything we want anytime we want. or is it too childish? -ss