search for: randrw

...75% write / 25% read -----------------|------|----------------------|--------------------- 1x rd_mcp LUN | 8 | ~155K IOPs | ~145K IOPs 16x rd_mcp LUNs | 16 | ~315K IOPs | ~305K IOPs 32x rd_mcp LUNs | 16 | ~425K IOPs | ~410K IOPs The full fio randrw results for the six test cases are attached below. Also, using a workload of fio numjobs > 16 currently makes performance start to fall off pretty sharply regardless of the number of vCPUs.. So running a similar workload with loopback SCSI ports on bare-metal produces ~1M random IOPs with 12x L...

...75% write / 25% read -----------------|------|----------------------|--------------------- 1x rd_mcp LUN | 8 | ~155K IOPs | ~145K IOPs 16x rd_mcp LUNs | 16 | ~315K IOPs | ~305K IOPs 32x rd_mcp LUNs | 16 | ~425K IOPs | ~410K IOPs The full fio randrw results for the six test cases are attached below. Also, using a workload of fio numjobs > 16 currently makes performance start to fall off pretty sharply regardless of the number of vCPUs.. So running a similar workload with loopback SCSI ports on bare-metal produces ~1M random IOPs with 12x L...

...uggested parameters. I'm running "fio" from a mounted gluster client: 172.16.0.12:/gv0 on /mnt2 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) # fio --ioengine=libaio --filename=fio.test --size=256M --direct=1 --rw=randrw --refill_buffers --norandommap --bs=8k --rwmixread=70 --iodepth=16 --numjobs=16 --runtime=60 --group_reporting --name=fio-test fio-test: (g=0): rw=randrw, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=16 ... fio-2.16 Starting 16 processes fio-test: Laying out IO file(s)...

...quot;fio" from a mounted gluster client: > 172.16.0.12:/gv0 on /mnt2 type fuse.glusterfs > (rw,relatime,user_id=0,group_id=0,default_permissions, > allow_other,max_read=131072) > > > > # fio --ioengine=libaio --filename=fio.test --size=256M > --direct=1 --rw=randrw --refill_buffers --norandommap > --bs=8k --rwmixread=70 --iodepth=16 --numjobs=16 > --runtime=60 --group_reporting --name=fio-test > fio-test: (g=0): rw=randrw, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, > iodepth=16 > ... > fio-2.16 > Starting 16 proces...

For vhost-scsi with 3 vqs and a workload like that tries to use those vqs like: fio --filename=/dev/sdb --direct=1 --rw=randrw --bs=4k \ --ioengine=libaio --iodepth=128 --numjobs=3 the single vhost worker thread will become a bottlneck and we are stuck at around 500K IOPs no matter how many jobs, virtqueues, and CPUs are used. To better utilize virtqueues and available CPUs, this patch allows userspace to create workers...

...k Inside vm i try to do some work via fio: [global] rw=randread size=128m directory=/tmp ioengine=libaio iodepth=4 invalidate=1 direct=1 [bgwriter] rw=randwrite iodepth=32 [queryA] iodepth=1 ioengine=mmap direct=0 thinktime=3 [queryB] iodepth=1 ioengine=mmap direct=0 thinktime=5 [bgupdater] rw=randrw iodepth=16 thinktime=40 size=128m After that i try to get graph like iowatcher -t test.trace -o trace.svg But svg contains unreadable images. What i doing wrong and how can i fix that? svg looks like http://62.76.182.4/trace.svg Thank you for good tools ! -- Vasiliy Tolstov, e-mail: v.tolstov@s...

...0 /mnt -o discard fio testcase umount /mnt --- [3] testcase [global] directory=/mnt rw=randread size=256m ioengine=libaio iodepth=4 invalidate=1 direct=1 [bgwriter] rw=randwrite iodepth=32 [queryA] iodepth=1 ioengine=mmap thinktime=3 [queryB] iodepth=1 ioengine=mmap thinktime=1 [bgupdater] rw=randrw iodepth=16 thinktime=1 size=32m -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

...2 4 8 12 16 ---------------------------------------------------------- 1 worker 160k 488k - - - - worker per vq 160k 310k 620k 1300k 1836k 2326k Notes: 0. This used a simple fio command: fio --filename=/dev/sdb --direct=1 --rw=randrw --bs=4k \ --ioengine=libaio --iodepth=128 --numjobs=$JOBS_ABOVE and I used a VM with 16 vCPUs and 16 virtqueues. 1. The patches were tested with LIO's emulate_pr=0 which drops the LIO PR lock use. This was a bottleneck at around 12 vqs/jobs. 2. Because we have a hard limit of 1024 cmds, if...

...OPS(k) Before After Improvement seq-read 138 437 +216% seq-write 191 436 +128% rnd-read 137 426 +210% rnd-write 140 415 +196% QEMU: Fio with libaio ioengine on 8 Ramdisk device 50% read + 50% write IOPS(k) Before After Improvement randrw 64/64 189/189 +195%/+195% Userspace bits: ----------------------------- 1) LKVM The latest vhost-blk userspace bits for kvm tool can be found here: git at github.com:asias/linux-kvm.git blk.vhost-blk 2) QEMU The latest vhost-blk userspace prototype for QEMU can be found here: git at gith...

...OPS(k) Before After Improvement seq-read 138 437 +216% seq-write 191 436 +128% rnd-read 137 426 +210% rnd-write 140 415 +196% QEMU: Fio with libaio ioengine on 8 Ramdisk device 50% read + 50% write IOPS(k) Before After Improvement randrw 64/64 189/189 +195%/+195% Userspace bits: ----------------------------- 1) LKVM The latest vhost-blk userspace bits for kvm tool can be found here: git at github.com:asias/linux-kvm.git blk.vhost-blk 2) QEMU The latest vhost-blk userspace prototype for QEMU can be found here: git at gith...

...D beeing over used). After install and reboot log in to VM and yum install epel-release -y && yum install screen fio htop -y and then run disk test: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test *--filename=test* --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 then *keep repeating *but *change the filename* attribute so it does not use the same blocks over and over again. In the beginning the performance is great!! Wow, very impressive 150MB/s 4k random r/w (close to bare metal, about 20% - 30% loss). But after a few (usually about 4...

...and reboot log in to VM and > > yum install epel-release -y && yum install screen fio htop -y > > and then run disk test: > > fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 > --name=test *--filename=test* --bs=4k --iodepth=64 --size=4G > --readwrite=randrw --rwmixread=75 > > then *keep repeating *but *change the filename* attribute so it does not > use the same blocks over and over again. > > In the beginning the performance is great!! Wow, very impressive 150MB/s > 4k random r/w (close to bare metal, about 20% - 30% loss). But afte...

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi folks, This series contains patches required to update tcm_vhost <-> virtio-scsi connected hosts <-> guests to run on v3.5-rc2 mainline code. This series is available on top of target-pending/auto-next here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git tcm_vhost This includes the necessary vhost

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi folks, This series contains patches required to update tcm_vhost <-> virtio-scsi connected hosts <-> guests to run on v3.5-rc2 mainline code. This series is available on top of target-pending/auto-next here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git tcm_vhost This includes the necessary vhost

This drops the cmd completion list spin lock and makes the cmd completion queue lock-less. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/tcm_vhost.c | 46 +++++++++++++--------------------------------- drivers/vhost/tcm_vhost.h | 2 +- 2 files changed, 14 insertions(+), 34 deletions(-) diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c index

This drops the cmd completion list spin lock and makes the cmd completion queue lock-less. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/tcm_vhost.c | 46 +++++++++++++--------------------------------- drivers/vhost/tcm_vhost.h | 2 +- 2 files changed, 14 insertions(+), 34 deletions(-) diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c index

...o VM and > > yum install epel-release -y && yum install screen fio htop -y > > and then run disk test: > > fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 > --name=test *--filename=test* --bs=4k --iodepth=64 --size=4G > --readwrite=randrw --rwmixread=75 > > then *keep repeating *but *change the filename* attribute so it > does not use the same blocks over and over again. > > In the beginning the performance is great!! Wow, very impressive > 150MB/s 4k random r/w (close to bare metal, about 20% - 30%...