linux-kernel - Re: zram: per-cpu compression 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]

Date:	Mon, 4 Apr 2016 10:17:02 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: zram: per-cpu compression streams

Hello Minchan,

On (04/04/16 09:27), Minchan Kim wrote:
> Hello Sergey,
> 
> On Sat, Apr 02, 2016 at 12:38:29AM +0900, Sergey Senozhatsky wrote:
> > Hello Minchan,
> > 
> > On (03/31/16 15:34), Sergey Senozhatsky wrote:
> > > > I tested with you suggested parameter.
> > > > In my side, win is better compared to my previous test but it seems
> > > > your test is so fast. IOW, filesize is small and loops is just 1.
> > > > Please test filesize=500m loops=10 or 20.
> > 
> > fio
> > - loops=10
> > - buffer_pattern=0xbadc0ffee
> > 
> > zram 6G. no intel p-state, deadline IO scheduler, no lockdep (no lock debugging).
> 
> We are using rw_page so I/O scheduler is not related.

yes, agree. added it just in case.

> Anyway, I configured my machine as you said but still see 10~20% enhance. :(
> Hmm, could you post your .config?

oh, sorry, completely forgot about it. attached.

> I want to investigate why such difference happens between our machines.
> 
> The reason I want to see such *big enhance* in my machine is that
> as you know, with per-cpu, zram's write path will lose blockable section
> so it would make upcoming features's implementation hard.

I see. well, depending on what new features are about to come in, we
can utilize the same per-cpu mechanism if we are talking about some
sort of buffers, streams, etc.

> We also should test it in very low memory situation so every write path
> retry it(i.e., dobule compression). With it, I want to see how many
> performance can drop.

one of the boxen I use has only 4G of memory, so "re-compressions" do
happen there. I can add a simple counter (just for testing purposes)
to see how often.

> If both test(normal: huge win low memory: small regression) are fine,
> we can go per-cpu approach at the cost of giving up blockable section.
> :)

yep.

	-ss

View attachment ".config" of type "text/plain" (91900 bytes)