Re: + zram-export-the-number-of-available-comp-streams.patch added to -mm tree
From: Sergey Senozhatsky
Date: Thu Mar 17 2016 - 21:36:53 EST
On (01/26/16 13:13), akpm@xxxxxxxxxxxxxxxxxxxx wrote:
> ------------------------------------------------------
> From: Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx>
> 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@xxxxxxxxx>
> Cc: Minchan Kim <minchan@xxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Andrew, may we ask you to drop this patch? this is not even a
"last second" request, sorry about that.
-ss