Hi Sergey,
On Tue, Oct 04, 2016 at 01:43:14PM +0900, Sergey Senozhatsky wrote:
< snip >
> TEST
> ****
>
> new tests results; same tests, same conditions, same .config.
> 4-way test:
> - BASE zram, fio direct=1
> - BASE zram, fio fsync_on_close=1
> - NEW zram, fio direct=1
> - NEW zram, fio fsync_on_close=1
>
>
>
> and what I see is that:
> - new zram is x3 times slower when we do a lot of direct=1 IO
> and
> - 10% faster when we use buffered IO (fsync_on_close); but not always;
> for instance, test execution time is longer (a reproducible behavior)
> when the number of jobs equals the number of CPUs - 4.
>
>
>
> if flushing is a problem for new zram during direct=1 test, then I would
> assume that writing a huge number of small files (creat/write 4k/close)
> would probably have same fsync_on_close=1 performance as direct=1.
>
>
> ENV
> ===
>
> x86_64 SMP (4 CPUs), "bare zram" 3g, lzo, static compression buffer.
>
>
> TEST COMMAND
> ============
>
> ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX={NEW, OLD} FIO_LOOPS=2
> ./zram-fio-test.sh
>
>
> EXECUTED TESTS
> ==============
>
> - [seq-read]
> - [rand-read]
> - [seq-write]
> - [rand-write]
> - [mixed-seq]
> - [mixed-rand]
>
>
> fio-perf-o-meter.sh test-fio-zram-OLD test-fio-zram-OLD-flush
> test-fio-zram-NEW test-fio-zram-NEW-flush
> Processing test-fio-zram-OLD
> Processing test-fio-zram-OLD-flush
> Processing test-fio-zram-NEW
> Processing test-fio-zram-NEW-flush
>
> BASE BASE NEW NEW
> direct=1 fsync_on_close=1 direct=1
> fsync_on_close=1
>
> #jobs1
>
> READ: 2345.1MB/s 2177.2MB/s 2373.2MB/s 2185.8MB/s
> READ: 1948.2MB/s 1417.7MB/s 1987.7MB/s 1447.4MB/s
> WRITE: 1292.7MB/s 1406.1MB/s 275277KB/s 1521.1MB/s
> WRITE: 1047.5MB/s 1143.8MB/s 257140KB/s 1202.4MB/s
> READ: 429530KB/s 779523KB/s 175450KB/s 782237KB/s
> WRITE: 429840KB/s 780084KB/s 175576KB/s 782800KB/s
> READ: 414074KB/s 408214KB/s 164091KB/s 383426KB/s
> WRITE: 414402KB/s 408539KB/s 164221KB/s 383730KB/s
I tested your benchmark for job 1 on my 4 CPU mahcine with this diff.
Nothing different.
1. just changed ordering of test execution - hope to reduce testing time due to
block population before the first reading or reading just zero pages
2. used sync_on_close instead of direct io
3. Don't use perf to avoid noise
4. echo 0 > /sys/block/zram0/use_aio to test synchronous IO for old behavior
diff --git a/conf/fio-template-static-buffer b/conf/fio-template-static-buffer
index 1a9a473..22ddee8 100644
--- a/conf/fio-template-static-buffer
+++ b/conf/fio-template-static-buffer
@@ -1,7 +1,7 @@
[global]
bs=${BLOCK_SIZE}k
ioengine=sync
-direct=1
+fsync_on_close=1
nrfiles=${NRFILES}
size=${SIZE}
numjobs=${NUMJOBS}
@@ -14,18 +14,18 @@ new_group
group_reporting
threads=1
-[seq-read]
-rw=read
-
-[rand-read]
-rw=randread
-
[seq-write]
rw=write
[rand-write]
rw=randwrite
+[seq-read]
+rw=read
+
+[rand-read]
+rw=randread
+
[mixed-seq]
rw=rw
diff --git a/zram-fio-test.sh b/zram-fio-test.sh
index 39c11b3..ca2d065 100755
--- a/zram-fio-test.sh
+++ b/zram-fio-test.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# Sergey Senozhatsky. sergey.senozhat...@gmail.com
@@ -37,6 +37,7 @@ function create_zram
echo $ZRAM_COMP_ALG > /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/comp_algorithm
+ echo 0 > /sys/block/zram0/use_aio
echo $ZRAM_SIZE > /sys/block/zram0/disksize
if [ $? != 0 ]; then
return -1
@@ -137,7 +138,7 @@ function main
echo "#jobs$i fio" >> $LOG
BLOCK_SIZE=4 SIZE=100% NUMJOBS=$i NRFILES=$i
FIO_LOOPS=$FIO_LOOPS \
- $PERF stat -o $LOG-perf-stat $FIO ./$FIO_TEMPLATE >>
$LOG
+ $FIO ./$FIO_TEMPLATE > $LOG
echo -n "perfstat jobs$i" >> $LOG
cat $LOG-perf-stat >> $LOG
And got following result.
1. ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=async FIO_LOOPS=2 MAX_ITER=1
./zram-fio-test.sh
2. modify script to disable aio via /sys/block/zram0/use_aio
ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX=sync FIO_LOOPS=2 MAX_ITER=1
./zram-fio-test.sh
seq-write 380930 474325 124.52%
rand-write 286183 357469 124.91%
seq-read 266813 265731 99.59%
rand-read 211747 210670 99.49%
mixed-seq(R) 145750 171232 117.48%
mixed-seq(W) 145736 171215 117.48%
mixed-rand(R) 115355 125239 108.57%
mixed-rand(W) 115371 125256 108.57%
LZO compression is fast and a CPU for queueing while 3 CPU for compressing
it cannot saturate CPU full bandwidth. Nonetheless, it shows 24% enhancement.
It could be more in slow CPU like embedded.
I tested it with deflate. The result is 300% enhancement.
seq-write 33598 109882 327.05%
rand-write 32815 102293 311.73%
seq-read 154323 153765 99.64%
rand-read 129978 129241 99.43%
mixed-seq(R) 15887 44995 283.22%
mixed-seq(W) 15885 44990 283.22%
mixed-rand(R) 25074 55491 221.31%
mixed-rand(W) 25078 55499 221.31%
So, curious with your test.
Am my test sync with yours? If you cannot see enhancment in job1, could
you test with deflate? It seems your CPU is really fast.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
