From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752068AbcCRBgu (ORCPT ); Thu, 17 Mar 2016 21:36:50 -0400 Received: from mail-pf0-f182.google.com ([209.85.192.182]:34581 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbcCRBgm (ORCPT ); Thu, 17 Mar 2016 21:36:42 -0400 Date: Fri, 18 Mar 2016 10:38:03 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: sergey.senozhatsky@gmail.com, minchan@kernel.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: + zram-export-the-number-of-available-comp-streams.patch added to -mm tree Message-ID: <20160318013803.GB572@swordfish> References: <56a7e192.va4HZ+5KNt2pr4kW%akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56a7e192.va4HZ+5KNt2pr4kW%akpm@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/26/16 13:13), akpm@linux-foundation.org wrote: > ------------------------------------------------------ > From: Sergey Senozhatsky > Subject: zram: export the number of available comp streams > > I've been asked several very simple questions: > a) How can I ensure that zram uses (or used) several compression > streams? > b) What is the current number of comp streams (how much memory > does zram *actually* use for compression streams, if there are > more than one stream)? > > zram, indeed, does not provide any info and does not answer these > questions. Reading from `max_comp_streams' let to estimate only > theoretical comp streams memory consumption, which assumes that zram will > allocate max_comp_streams. However, it's possible that the real number of > compression streams will never reach that max value, due to various > reasons, e.g. max_comp_streams is too high, etc. > > The patch adds `avail_streams' column to the /sys/block/zram/mm_stat > device file. For a single compression stream backend it's always 1, for a > multi stream backend - it shows the actual ->avail_strm value. > > The number of allocated compression streams answers several > questions: > a) the current `level of concurrency' that the device has > experienced > b) the amount of memory used by compression streams (by multiplying > the `avail_streams' column value, ->buffer size and algorithm's > specific scratch buffer size; the last are easy to find out, > unlike `avail_streams'). > > Signed-off-by: Sergey Senozhatsky > Cc: Minchan Kim > Signed-off-by: Andrew Morton Andrew, may we ask you to drop this patch? this is not even a "last second" request, sorry about that. -ss