Re: + zram-export-the-number-of-available-comp-streams.patch added to -mm tree

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (01/26/16 13:13), akpm@linux-foundation.org wrote:
> ------------------------------------------------------
> From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> 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<id>/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 <sergey.senozhatsky@gmail.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>


Andrew, may we ask you to drop this patch? this is not even a
"last second" request, sorry about that.

	-ss