From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755387AbbCELnB (ORCPT ); Thu, 5 Mar 2015 06:43:01 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:33377 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752723AbbCELm7 (ORCPT ); Thu, 5 Mar 2015 06:42:59 -0500 Date: Thu, 5 Mar 2015 20:43:23 +0900 From: Sergey Senozhatsky To: minchan@kernel.org 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, Sergey Senozhatsky Subject: Re: + zram-support-compaction.patch added to -mm tree Message-ID: <20150305114322.GA623@swordfish> References: <54f780fc.3sOWZKr7rufmI85r%akpm@linux-foundation.org> <20150305052941.GK14927@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305052941.GK14927@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 (03/05/15 14:29), Sergey Senozhatsky wrote: > On (03/04/15 14:02), akpm@linux-foundation.org wrote: > > +What: /sys/block/zram/compact > > +Date: August 2015 > > +Contact: Minchan Kim > > +Description: > > + The compact file is write-only and trigger compaction for > > + allocator zrm uses. The allocator moves some objects so that > > + it could free fragment space. > > + > > +What: /sys/block/zram/num_migrated > > +Date: August 2015 > > +Contact: Minchan Kim > > +Description: > > + The compact file is read-only and shows how many object > > + migrated by compaction. > Minchan, do you want to provide num_migrated as part of zsmalloc stats rather > than having yet another zram attr? we already provide zsmalloc stats and this > type of information seems to belong there. just idea. > can compaction memory gain be calculated as, for example, mem_used_total #before_compaction - mem_used_total #after_compaction ? if yes, then do we need this attr at all? the other thing is - why does this attr return the sum of all compactions? wouldn't it be more informative to return the number of bytes gained after the most recent compaction? but, once again, is this attr worth having? -ss