Question: how fast the emulated device can be? or how to improve the latency/through put

[fengggli]

Hi, I am using the scripts like the below to launch my guest, where nvme.img is a raw disk img.

qemu-system-x86064 -m 2G \
                   -cpu SandyBridge \
                   -machine q35 \   
                   -hda ${SYSTEM_IMG} \
                   -net nic \
                   -net user,hostfwd=tcp::2222-:22 \
                   -drive file=${nvme.img},format=raw,if=none,id=drv0 \
                   -device nvme,drive=drv0,serial=foo0,lver=1,lba_index=3,nlbaf=5,namespaces=1,addr=06.0 \
                   -virtfs local,id=mdev,path=/home/lifeng/Workspace,security_model=none,mount_tag=Workspace \
                   -smp 4 \
                   -enable-kvm 

In the guest, i use fio and it give me 55us second latency and around 70MB/s for 4kwrite:

sudo fio -filename=/dev/nvme0n1 -direct=1 -rw=write -bs=4k -size=100G -runtime=10 -group_reporting -name=test_write

Is there any approach to make the device behave more like the real device(in the sense of lower latency and higher bandwidth)?

I tried to create nvme.img in tmpfs(ramdisk), but still get the same performance.

Any suggestion is appreciated

[javigon]

Hi Feng,

As for now, qemu is for sanity check, not for performance evaluation. Latencies will always be unreliable in the current implementation.

I'm sure the qemu backend can be improved to work more as a simulator (using memory as a backend is a good start), but it is not I am planning to implement in the near future. Maybe others will. If so, please comment.

Javier

[MatiasBjorling]

Hi Feng,

If you want, you can use the null_blk driver, that implements a memory backend. (See for-4.19/null_blk branches). Although you will need to couple it with the zoned interface usage.