linux-kernel - Re: [PATCH] zram: export the number of available comp streams

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160129072842.GA30072@bbox>
Date:	Fri, 29 Jan 2016 16:28:42 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH] zram: export the number of available comp streams

Hello Sergey,

Sorry to late response. Thesedays, I'm really busy with personal
stuff.

Today, I have thought about this patch and have several questions.
Let's start with simple questions.

On Tue, Jan 26, 2016 at 09:03:59PM +0900, Sergey Senozhatsky wrote:
> I've been asked several very simple questions:
> a) How can I ensure that zram uses (or used) several compression
>    streams?

Why does he want to ensure several compression streams?
As you know well, zram handle it dynamically.

If zram cannot allocate more streams, it means the system is
heavily fragmented or memory pressure at that time so there
is no worth to add more stream, I think.

Could you elaborate it more why he want to know it and what
he expect from that?

> 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)?

Hmm, in the kernel, there are lots of example subsystem
we cannot know exact memory usage. Why does the user want
to know exact memory usage of zram? What is his concern?

In advance, sorry for slow response.

> 
> 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>