[<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)
Powered by blists - more mailing lists