Hello Minchan,
On (03/31/16 14:53), Minchan Kim wrote:
> Hello Sergey,
>
> > that's a good question. I quickly looked into the fio source code,
> > we need to use "buffer_pattern=str" option, I think. so the buffers
> > will be filled with the same data.
> >
> > I don't mind to have buffer_compress_percentage as a separate test (set
> > as a local test option), but I think that using common buffer pattern
> > adds more confidence when we compare test results.
>
> If we both uses same "buffer_compress_percentage=something", it's
> good to compare. The benefit of buffer_compress_percentage is we can
> change compression ratio easily in zram testing and see various
> test to see what compression ratio or speed affects the system.
let's start with "common data" (buffer_pattern=str), not common
compression ratio. buffer_compress_percentage=something is calculated
for which compression algorithm? deflate (zlib)? or it's something else?
we use lzo/lz4, common data is more predictable.
[..]
> > sure.
>
> 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.
that will require 5G zram, I don't have that much ram on the box so I'll
test later today on another box.
I split the device size between jobs. if I have 10 jobs, then the file
size of each job is DISK_SIZE/10; but in total jobs write/read DEVICE_SZ
bytes. jobs start with large 1 * DEVICE_SZ/1 files and go down to
10 * DEVICE_SZ/10 files.
> It can make your test more stable and enhance is 10~20% in my side.
> Let's discuss further once test result between us is consistent.
-ss
