From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751927AbbCJFhy (ORCPT ); Tue, 10 Mar 2015 01:37:54 -0400 Received: from mail-pd0-f172.google.com ([209.85.192.172]:44771 "EHLO mail-pd0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117AbbCJFht (ORCPT ); Tue, 10 Mar 2015 01:37:49 -0400 Date: Tue, 10 Mar 2015 14:37:52 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , 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: <20150310053752.GA6330@swordfish> References: <20150305052941.GK14927@swordfish> <20150309004859.GB15184@blaptop> <20150309005718.GA794@swordfish> <20150309010522.GD15184@blaptop> <20150309012728.GB794@swordfish> <20150309014702.GE15184@blaptop> <20150309020717.GC794@swordfish> <20150309022127.GF15184@blaptop> <20150309064856.GE794@swordfish> <20150309145639.GA7860@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309145639.GA7860@blaptop> 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 (03/09/15 23:56), Minchan Kim wrote: > > in zram_slot_free_notify() and zram_rw_page() we don't have request queue, request, > > etc. so it's a bit troubling. > > I skim the code so I might miss something. > > zram_slot_free_notify is just to free allocated space on zsmalloc so > it's not related to I/O operation so it would be okay if we handle > make_request and rw_page. Fortunately, they share core function > called by zram_bvec_rw. So could we use generic_[start|end]_io_acct > in there? It seems we don't need request queue. > that will do the trick, I think. thanks. I found these two late last night. > > > > Name units description > > ---- ----- ----------- > > read I/Os requests number of read I/Os processed > > read merges requests number of read I/Os merged with in-queue I/O > > read sectors sectors number of sectors read > > read ticks milliseconds total wait time for read requests > > write I/Os requests number of write I/Os processed > > write merges requests number of write I/Os merged with in-queue I/O > > write sectors sectors number of sectors written > > write ticks milliseconds total wait time for write requests > > in_flight requests number of I/Os currently in flight > > io_ticks milliseconds total time this block device has been active > > time_in_queue milliseconds total wait time for all requests > > > > > > the only overlaps are num_read and num_write. so we will not be able to move all > > When I read above, read/write ticks would be useful to us. yes. somehow I didn't manage to shape my thoughts, I was going to say that this stat file is surely interesting on his own; and was about to let num_reads and num_writes to sit in both zram/stat and zram/io_stat files. > > (or any significant amount) of our IO stats to that file. that will force users > > to gather IO stats accross several files. > > I'm not saying let's move all of I/O related stuff. > What I want is to remove duplicated stat if it is and enable zram/stats > so I hope we could use iostat/nmon to monitor zram I/O. ok. I did some overlapping (as I mentioned above) -- num_reads and num_writes present in both ./stat and ./io_stat files. will remove them. so we end up having: -- block layer stats in zram/stat -- zram internal IO stats in zram/io_stat (no num_reads, no num_writes) -- zram mm stats in zram/mm_stat (orig size, compressed size, num_migrated, etc.) > > > > I'll take a look later today/tomorrow if I can do anything about it, but it seems > > that our own zramX/io_stat file would be simpler solution here. it does sound ugly, > > but it doesn't look so bad after all. > > If it is really impossible or makes kernel complicated, I will agree with you. > Otherwise, I really want to see zram in iostat. :) yes, that's the goal. I found our previous discussion on the topic: https://lkml.org/lkml/2014/9/4/368 6 months later we are finally on it :) will send the patches later today. thanks, -ss