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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20160318013803.GB572@swordfish>
Date:	Fri, 18 Mar 2016 10:38:03 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	sergey.senozhatsky@...il.com, minchan@...nel.org,
	mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: + zram-export-the-number-of-available-comp-streams.patch added
 to -mm tree

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


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

	-ss