runtime 🚀 - Poor qemu-virtiofs performance in benchmarks

@jcrowthe thanks for raising this, cc'ing virtiofs experts

cc @stefanha @dagrh

devimc on 16 Oct 2019

@jcrowthe Can you share with us the exact fio command you used?

I've experienced poor fio performance when the --size parameter is larger than the virtio-fs cache size virtio_fs_cache_size.

awprice on 17 Oct 2019

@jcrowthe Can you uncomment

enable_debug = true

line and get some logs.

And copy the qemu command line， Thanks!

fuxiao511 on 17 Oct 2019

@jcrowthe Can you paste the fio configration here ?

Kvasscn on 17 Oct 2019

Can you also give us some idea of the cache size you're using?
Also, how does it compare with cache-size=0 (i.e. no dax)

dagrh on 17 Oct 2019

@jcrowthe Sorry if I missed it, but please post your fio job file and command-line so we know what you benchmarked.

stefanha on 17 Oct 2019

Hey, I tried a few different variations of this, but the following is the fio command used:

fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_reporting --fallocate=none --time_based --thread --invalidate=1

Size is set to the same as the default virtio cache size. The results I provided in the original post was with only one thread/job, though I also ran multiple job benchmarks (hence the flags included here).

My next test will be to launch multiple nodes and provide an average across multiple runs per test, per node. This will help avoid potential noisy neighbor (as it is the cloud). If you have further tests you'd like me to run, feel free to mention it. I was unable to run additional tests today, but can enable_debug as well in the next round. Thanks!

jcrowthe on 18 Oct 2019

👍1

On Fri, Oct 18, 2019 at 6:00 AM Jacob Crowther notifications@github.com
wrote:

fio --name=random-readers --filename=testfile --ioengine=libaio
--iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1
--runtime=60s --group_reporting --fallocate=none --time_based --thread
--invalidate=1

A 1 GB file fits within Kata's default 1 GB DAX Window (512 x 2 MB
chunks). Although setting up these 512 DAX Window mappings takes a little
bit of time, I wouldn't expect this to significantly affect a runtime=60s
benchmark.

The direct=0 option should have no effect here since Kata uses DAX by
default (the guest page cache is bypassed).

This all suggests that DAX isn't to blame for poor performance, but it
would be interesting to disable it just in case. If you're able to
recompile kata-runtime it would be interesting to comment out the following
in virtcontainers/kata_agent.go:setupStorages() and run 'make' again to get
a patched kata-runtime binary:
if sandbox.config.HypervisorConfig.VirtioFSCache != typeVirtioFSNoCache { sharedDirVirtioFSOptions = append(sharedDirVirtioFSOptions, sharedDirVirtioFSDaxOptions) }

stefanha on 18 Oct 2019

@stefanha I compiled out DAX as per your comment, and the results were surprising:
qemu-virtiofs-patched: 252K IOPs

fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)

Jobs: 1 (f=1): [r(1)][100.0%][r=180MiB/s,w=0KiB/s][r=369k,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=19: Wed Oct 23 17:58:13 2019
   read: IOPS=252k, BW=123MiB/s (129MB/s)(7388MiB/60000msec)
    slat (usec): min=1, max=8629, avg= 2.86, stdev=15.10
    clat (usec): min=2, max=15610, avg=60.12, stdev=116.37
     lat (usec): min=3, max=16582, avg=62.99, stdev=122.99
    clat percentiles (usec):
     |  1.00th=[   36],  5.00th=[   37], 10.00th=[   38], 20.00th=[   38],
     | 30.00th=[   38], 40.00th=[   38], 50.00th=[   39], 60.00th=[   39],
     | 70.00th=[   39], 80.00th=[   40], 90.00th=[   60], 95.00th=[  112],
     | 99.00th=[  652], 99.50th=[  836], 99.90th=[ 1080], 99.95th=[ 1240],
     | 99.99th=[ 2928]
    lat (usec) : 4=0.01%, 10=0.01%, 20=0.01%, 50=87.45%, 100=6.75%
    lat (usec) : 250=2.84%, 500=1.41%, 750=0.84%, 1000=0.54%
    lat (msec) : 2=0.16%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=27.02%, sys=52.52%, ctx=281340, majf=0, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=15130957,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=123MiB/s (129MB/s), 123MiB/s-123MiB/s (129MB/s-129MB/s), io=7388MiB (7747MB), run=60000-60000msec

252K IOPs seems... excessive. I tested the other two cases in the same environment:
qemu-patched: 19.4K IOPs

random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)

Jobs: 1 (f=0): [f(1)][100.0%][r=9671KiB/s,w=0KiB/s][r=19.4k,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=13: Wed Oct 23 18:11:17 2019
   read: IOPS=19.3k, BW=9512KiB/s (9740kB/s)(557MiB/60001msec)
    slat (usec): min=19, max=11450, avg=48.35, stdev=57.82
    clat (usec): min=5, max=39860, avg=790.12, stdev=319.23
     lat (usec): min=80, max=40173, avg=838.47, stdev=333.12
    clat percentiles (usec):
     |  1.00th=[  708],  5.00th=[  708], 10.00th=[  716], 20.00th=[  724],
     | 30.00th=[  732], 40.00th=[  740], 50.00th=[  748], 60.00th=[  764],
     | 70.00th=[  780], 80.00th=[  812], 90.00th=[  868], 95.00th=[  940],
     | 99.00th=[ 1192], 99.50th=[ 1512], 99.90th=[ 3824], 99.95th=[ 7136],
     | 99.99th=[15424]
    lat (usec) : 10=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=48.32%
    lat (usec) : 1000=49.00%
    lat (msec) : 2=2.40%, 4=0.18%, 10=0.07%, 20=0.02%, 50=0.01%
  cpu          : usr=7.43%, sys=40.16%, ctx=1145350, majf=0, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=1141477,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=9512KiB/s (9740kB/s), 9512KiB/s-9512KiB/s (9740kB/s-9740kB/s), io=557MiB (584MB), run=60001-60001msec

runc: 130K IOPs

fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=63.5MiB/s,w=0KiB/s][r=130k,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=36: Wed Oct 23 18:22:41 2019
   read: IOPS=69.3k, BW=33.9MiB/s (35.5MB/s)(2028MiB/60001msec)
    slat (usec): min=2, max=12539, avg= 9.92, stdev=32.68
    clat (usec): min=41, max=14430, avg=218.47, stdev=294.80
     lat (usec): min=45, max=14544, avg=228.39, stdev=312.09
    clat percentiles (usec):
     |  1.00th=[   82],  5.00th=[   83], 10.00th=[   86], 20.00th=[   93],
     | 30.00th=[  105], 40.00th=[  112], 50.00th=[  115], 60.00th=[  129],
     | 70.00th=[  149], 80.00th=[  205], 90.00th=[  458], 95.00th=[  876],
     | 99.00th=[ 1512], 99.50th=[ 1656], 99.90th=[ 2040], 99.95th=[ 2416],
     | 99.99th=[ 4640]
    lat (usec) : 50=0.01%, 100=25.62%, 250=57.66%, 500=7.48%, 750=3.14%
    lat (usec) : 1000=2.10%
    lat (msec) : 2=3.90%, 4=0.10%, 10=0.01%, 20=0.01%
  cpu          : usr=29.94%, sys=35.08%, ctx=262347, majf=0, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=4153625,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=33.9MiB/s (35.5MB/s), 33.9MiB/s-33.9MiB/s (35.5MB/s-35.5MB/s), io=2028MiB (2127MB), run=60001-60001msec

We weren't compiling Kata before and I was worried about differences between the version we had and what I had just compiled. I decided to compile kata without the patch and tested again.
qemu-virtiofs unpatched: 3681 IOPs

/ # fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16
 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_r
eporting --fallocate=none --time_based --thread --invalidate=1
random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=1840KiB/s,w=0KiB/s][r=3681,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=15: Wed Oct 23 18:56:46 2019
   read: IOPS=3836, BW=1918KiB/s (1964kB/s)(112MiB/60001msec)
    slat (usec): min=1, max=11640, avg=243.51, stdev=392.91
    clat (usec): min=23, max=26557, avg=3920.33, stdev=3711.31
     lat (usec): min=223, max=26973, avg=4163.84, stdev=3835.59
    clat percentiles (usec):
     |  1.00th=[  306],  5.00th=[  620], 10.00th=[  780], 20.00th=[ 1020],
     | 30.00th=[ 1240], 40.00th=[ 1496], 50.00th=[ 1864], 60.00th=[ 3088],
     | 70.00th=[ 5472], 80.00th=[ 7840], 90.00th=[ 9408], 95.00th=[10944],
     | 99.00th=[14656], 99.50th=[15680], 99.90th=[18048], 99.95th=[19072],
     | 99.99th=[21888]
    lat (usec) : 50=0.01%, 250=0.18%, 500=2.12%, 750=7.00%, 1000=9.65%
    lat (msec) : 2=33.14%, 4=11.80%, 10=28.91%, 20=7.16%, 50=0.03%
  cpu          : usr=8.29%, sys=16.92%, ctx=148103, majf=0, minf=3329
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=230178,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=1918KiB/s (1964kB/s), 1918KiB/s-1918KiB/s (1964kB/s-1964kB/s), io=112MiB (118MB), run=60001-60001msec

Not really sure what to make of this.

evanfoster on 23 Oct 2019

I've not followed/read the details of this thread, and @stefanha and @dagrh will likely have a much better insight, but traditionally with Kata when we see unexpected 'better than non-VM' type performance, we find that something is caching the results (possibly on the host side), and the numbers you are seeing are effectively the performance of the cache, not the performance of the 'whole chain' iyswim.

grahamwhaley on 24 Oct 2019

@evanfoster fio is launched with --direct=0 so the guest page cache will be used. Therefore some I/O requests will never be sent to the host. DAX is a bit different, it bypasses the guest page cache and involves some setup/teardown for memory mappings that the guest kernel makes in 2 MB chunks, making it bad at random I/O workloads.

It's possible that the DAX mappings are thrashing, causing lots of repeated setup/teardown, but your DAX Window size should be large enough to hold this file...

Regarding the high fio result once DAX is disabled - your benchmark is only hitting the guest page cache, so it's just affected by guest memory bandwidth and guest kernel page cache management algorithms. If you are comparing against another container runtime or bare metal you need to be sure the page cache size and kernel version are the same, otherwise the performance could be quite different.

The main question I'm wondering about is why DAX wasn't able to map the entire file. Then it should have performed well.

I probably won't have time to look at this over the next week because I will be away. Please ping me afterwards if you'd like me to investigate further.

stefanha on 25 Oct 2019

👍3

I have an update for this issue!

I was able to get virtiofs to perform far better by changing two things:

Changing the runtime type in CRI-O from oci to vm, e.g.:

[crio.runtime.runtimes.kata-qemu-vm]
runtime_path = "/opt/kata/bin/containerd-shim-kata-v2"
runtime_type = "vm"

Setting the size of the DAX cache in /etc/kata-containers/configuration.toml to 0:

virtio_fs_cache_size = 0

I did not compile DAX out, just set the cache size to 0.

I then performed the following benchmarks:

# virtiofs with DAX
/test-volume # fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_reporting --fallocate=none --time_based --thread --invalidate=1
random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=1751KiB/s,w=0KiB/s][r=3503,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=15: Thu May 28 17:15:34 2020
   read: IOPS=3817, BW=1909KiB/s (1955kB/s)(112MiB/60001msec)
    slat (usec): min=1, max=45343, avg=213.97, stdev=595.72
    clat (usec): min=4, max=62778, avg=3969.89, stdev=5405.74
     lat (usec): min=195, max=62797, avg=4183.85, stdev=5560.79
    clat percentiles (usec):
     |  1.00th=[  235],  5.00th=[  274], 10.00th=[  426], 20.00th=[  572],
     | 30.00th=[  732], 40.00th=[  884], 50.00th=[ 1080], 60.00th=[ 1464],
     | 70.00th=[ 4256], 80.00th=[ 8640], 90.00th=[11200], 95.00th=[14144],
     | 99.00th=[22912], 99.50th=[27264], 99.90th=[37632], 99.95th=[43264],
     | 99.99th=[52480]
    lat (usec) : 10=0.01%, 250=2.58%, 500=12.62%, 750=16.33%, 1000=14.86%
    lat (msec) : 2=17.20%, 4=5.75%, 10=14.47%, 20=14.34%, 50=1.84%
    lat (msec) : 100=0.02%
  cpu          : usr=9.64%, sys=26.30%, ctx=115767, majf=0, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=229082,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=1909KiB/s (1955kB/s), 1909KiB/s-1909KiB/s (1955kB/s-1955kB/s), io=112MiB (117MB), run=60001-60001msec


# 9p
/test-volume # fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_reporting --fallocate=none --time_based --thread --invalidate=1
random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=4962KiB/s,w=0KiB/s][r=9925,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=23: Thu May 28 17:20:49 2020
   read: IOPS=14.9k, BW=7429KiB/s (7607kB/s)(435MiB/60001msec)
    slat (usec): min=18, max=15522, avg=63.57, stdev=125.11
    clat (usec): min=5, max=21705, avg=1011.02, stdev=558.16
     lat (usec): min=113, max=21863, avg=1074.59, stdev=579.39
    clat percentiles (usec):
     |  1.00th=[  636],  5.00th=[  716], 10.00th=[  756], 20.00th=[  828],
     | 30.00th=[  860], 40.00th=[  908], 50.00th=[  948], 60.00th=[  972],
     | 70.00th=[ 1012], 80.00th=[ 1064], 90.00th=[ 1256], 95.00th=[ 1464],
     | 99.00th=[ 2064], 99.50th=[ 3440], 99.90th=[10432], 99.95th=[11584],
     | 99.99th=[13120]
    lat (usec) : 10=0.01%, 250=0.01%, 500=0.01%, 750=9.46%, 1000=57.25%
    lat (msec) : 2=32.22%, 4=0.63%, 10=0.33%, 20=0.11%, 50=0.01%
  cpu          : usr=6.91%, sys=37.43%, ctx=889788, majf=0, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=891493,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=7429KiB/s (7607kB/s), 7429KiB/s-7429KiB/s (7607kB/s-7607kB/s), io=435MiB (456MB), run=60001-60001msec

# runc
/test-volume # fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_reporting --fallocate=none --time_based --thread --invalidate=1
random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=8817KiB/s,w=0KiB/s][r=17.7k,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=26: Thu May 28 17:27:42 2020
   read: IOPS=13.8k, BW=6892KiB/s (7058kB/s)(404MiB/60001msec)
    slat (usec): min=2, max=22801, avg=68.37, stdev=88.24
    clat (usec): min=6, max=23808, avg=1089.87, stdev=425.91
     lat (usec): min=202, max=23897, avg=1158.24, stdev=444.02
    clat percentiles (usec):
     |  1.00th=[  532],  5.00th=[  660], 10.00th=[  732], 20.00th=[  828],
     | 30.00th=[  900], 40.00th=[  972], 50.00th=[ 1048], 60.00th=[ 1112],
     | 70.00th=[ 1192], 80.00th=[ 1288], 90.00th=[ 1464], 95.00th=[ 1640],
     | 99.00th=[ 2160], 99.50th=[ 2608], 99.90th=[ 5920], 99.95th=[ 7264],
     | 99.99th=[11072]
    lat (usec) : 10=0.01%, 250=0.01%, 500=0.58%, 750=11.12%, 1000=32.38%
    lat (msec) : 2=54.41%, 4=1.29%, 10=0.20%, 20=0.02%, 50=0.01%
  cpu          : usr=7.21%, sys=21.41%, ctx=592355, majf=4, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=827076,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
   READ: bw=6892KiB/s (7058kB/s), 6892KiB/s-6892KiB/s (7058kB/s-7058kB/s), io=404MiB (423MB), run=60001-60001msec

# virtiofs without DAX
/test-volume # fio --name=random-readers --filename=testfile --ioengine=libaio --iodepth=16 --rw=randread --bs=512 --direct=0 --size=1G --numjobs=1 --runtime=60s --group_reporting --fallocate=none --time_based --thread --invalidate=1
random-readers: (g=0): rw=randread, bs=512B-512B,512B-512B,512B-512B, ioengine=libaio, iodepth=16
fio-2.17-45-g06cb
Starting 1 thread
random-readers: Laying out IO file(s) (1 file(s) / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=6122KiB/s,w=0KiB/s][r=12.3k,w=0 IOPS][eta 00m:00s]
random-readers: (groupid=0, jobs=1): err= 0: pid=24: Thu May 28 17:32:06 2020
   read: IOPS=13.3k, BW=6614KiB/s (6773kB/s)(388MiB/60001msec)
    slat (usec): min=1, max=12720, avg=73.31, stdev=125.95
    clat (usec): min=3, max=24642, avg=1134.91, stdev=712.64
     lat (usec): min=123, max=24795, avg=1208.22, stdev=744.35
    clat percentiles (usec):
     |  1.00th=[  532],  5.00th=[  660], 10.00th=[  740], 20.00th=[  836],
     | 30.00th=[  908], 40.00th=[  972], 50.00th=[ 1032], 60.00th=[ 1096],
     | 70.00th=[ 1160], 80.00th=[ 1240], 90.00th=[ 1400], 95.00th=[ 1704],
     | 99.00th=[ 4320], 99.50th=[ 5920], 99.90th=[ 9408], 99.95th=[10816],
     | 99.99th=[14912]
    lat (usec) : 4=0.01%, 250=0.01%, 500=0.67%, 750=10.13%, 1000=34.18%
    lat (msec) : 2=51.63%, 4=2.18%, 10=1.13%, 20=0.08%, 50=0.01%
  cpu          : usr=4.71%, sys=36.92%, ctx=563989, majf=3, minf=1
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=793694,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
   READ: bw=6614KiB/s (6773kB/s), 6614KiB/s-6614KiB/s (6773kB/s-6773kB/s), io=388MiB (406MB), run=60001-60001msec

We jumped from ~3K IOPs to 12K IOPs, when a regular CRI-O container is getting 17K IOPs.

Version info and config:

Click to expand

vmss-agent-kata-vmss-test-jsuwk000002 bin # ./kata-runtime --version
kata-runtime  : 1.10.0-adobe
   commit   : 2d2b8878c511d6f5ba65a6152c577608ee27e45d-dirty
   OCI specs: 1.0.1-dev
vmss-agent-kata-vmss-test-jsuwk000002 bin # kubelet --version
Kubernetes v1.16.9
vmss-agent-kata-vmss-test-jsuwk000002 bin # crictl version
Version:  0.1.0
RuntimeName:  cri-o
RuntimeVersion:  1.17.4
RuntimeApiVersion:  v1alpha1
vmss-agent-kata-vmss-test-jsuwk000002 bin # cat /etc/kata-containers/configuration.toml
# Copyright (c) 2017-2019 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration-qemu-virtiofs.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/opt/kata/bin/qemu-virtiofs-system-x86_64"
kernel = "/opt/kata/share/kata-containers/vmlinuz-virtiofs.container"
image = "/opt/kata/share/kata-containers/kata-containers.img"
machine_type = "pc"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = ""

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
default_memory = 2048
#
# Default memory slots per SB/VM.
# If unspecified then it will be set 10.
# This is will determine the times that memory will be hotadded to sandbox/VM.
memory_slots = 50

# The size in MiB will be plused to max memory of hypervisor.
# It is the memory address space for the NVDIMM devie.
# If set block storage driver (block_device_driver) to "nvdimm",
# should set memory_offset to the size of block device.
# Default 0
#memory_offset = 0

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons.
# This flag prevents the block device from being passed to the hypervisor,
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Shared file system type:
#   - virtio-fs (default)
#   - virtio-9p
shared_fs = "virtio-fs"

# Path to vhost-user-fs daemon.
virtio_fs_daemon = "/opt/kata/bin/virtiofsd"

# Default size of DAX cache in MiB
# virtio_fs_cache_size = 1024
virtio_fs_cache_size = 0

# Extra args for virtiofsd daemon
#
# Format example:
#   ["-o", "arg1=xxx,arg2", "-o", "hello world", "--arg3=yyy"]
#
# see `virtiofsd -h` for possible options.
virtio_fs_extra_args = []

# Cache mode:
#
#  - none
#    Metadata, data, and pathname lookup are not cached in guest. They are
#    always fetched from host and any changes are immediately pushed to host.
#
#  - auto
#    Metadata and pathname lookup cache expires after a configured amount of
#    time (default is 1 second). Data is cached while the file is open (close
#    to open consistency).
#
#  - always
#    Metadata, data, and pathname lookup are cached in guest and never expire.
virtio_fs_cache = "always"

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is virtio-scsi, virtio-blk
# or nvdimm.
block_device_driver = "virtio-scsi"

# Specifies cache-related options will be set to block devices or not.
# Default false
#block_device_cache_set = true

# Specifies cache-related options for block devices.
# Denotes whether use of O_DIRECT (bypass the host page cache) is enabled.
# Default false
#block_device_cache_direct = true

# Specifies cache-related options for block devices.
# Denotes whether flush requests for the device are ignored.
# Default false
#block_device_cache_noflush = true

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically
# result in memory pre allocation
#enable_hugepages = true

# Enable file based guest memory support. The default is an empty string which
# will disable this feature. In the case of virtio-fs, this is enabled
# automatically and '/dev/shm' is used as the backing folder.
# This option will be ignored if VM templating is enabled.
#file_mem_backend = ""

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
#
# Default false
#enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
#
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes
# used for 9p packet payload.
#msize_9p = 8192

# If true and vsocks are supported, use vsocks to communicate directly
# with the agent and no proxy is started, otherwise use unix
# sockets and start a proxy to communicate with the agent.
# Default false
use_vsock = true

# VFIO devices are hotplugged on a bridge by default.
# Enable hotplugging on root bus. This may be required for devices with
# a large PCI bar, as this is a current limitation with hotplugging on
# a bridge. This value is valid for "pc" machine type.
# Default false
#hotplug_vfio_on_root_bus = true

# If vhost-net backend for virtio-net is not desired, set to true. Default is false, which trades off
# security (vhost-net runs ring0) for network I/O performance.
#disable_vhost_net = true

#
# Default entropy source.
# The path to a host source of entropy (including a real hardware RNG)
# /dev/urandom and /dev/random are two main options.
# Be aware that /dev/random is a blocking source of entropy.  If the host
# runs out of entropy, the VMs boot time will increase leading to get startup
# timeouts.
# The source of entropy /dev/urandom is non-blocking and provides a
# generally acceptable source of entropy. It should work well for pretty much
# all practical purposes.
#entropy_source= "/dev/urandom"

# Path to OCI hook binaries in the *guest rootfs*.
# This does not affect host-side hooks which must instead be added to
# the OCI spec passed to the runtime.
#
# You can create a rootfs with hooks by customizing the osbuilder scripts:
# https://github.com/kata-containers/osbuilder
#
# Hooks must be stored in a subdirectory of guest_hook_path according to their
# hook type, i.e. "guest_hook_path/{prestart,postart,poststop}".
# The agent will scan these directories for executable files and add them, in
# lexicographical order, to the lifecycle of the guest container.
# Hooks are executed in the runtime namespace of the guest. See the official documentation:
# https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-hooks
# Warnings will be logged if any error is encountered will scanning for hooks,
# but it will not abort container execution.
#guest_hook_path = "/usr/share/oci/hooks"

[factory]
# VM templating support. Once enabled, new VMs are created from template
# using vm cloning. They will share the same initial kernel, initramfs and
# agent memory by mapping it readonly. It helps speeding up new container
# creation and saves a lot of memory if there are many kata containers running
# on the same host.
#
# When disabled, new VMs are created from scratch.
#
# Note: Requires "initrd=" to be set ("image=" is not supported).
#
# Default false
#enable_template = true

# Specifies the path of template.
#
# Default "/run/vc/vm/template"
#template_path = "/run/vc/vm/template"

# The number of caches of VMCache:
# unspecified or == 0   --> VMCache is disabled
# > 0                   --> will be set to the specified number
#
# VMCache is a function that creates VMs as caches before using it.
# It helps speed up new container creation.
# The function consists of a server and some clients communicating
# through Unix socket.  The protocol is gRPC in protocols/cache/cache.proto.
# The VMCache server will create some VMs and cache them by factory cache.
# It will convert the VM to gRPC format and transport it when gets
# requestion from clients.
# Factory grpccache is the VMCache client.  It will request gRPC format
# VM and convert it back to a VM.  If VMCache function is enabled,
# kata-runtime will request VM from factory grpccache when it creates
# a new sandbox.
#
# Default 0
#vm_cache_number = 0

# Specify the address of the Unix socket that is used by VMCache.
#
# Default /var/run/kata-containers/cache.sock
#vm_cache_endpoint = "/var/run/kata-containers/cache.sock"

[proxy.kata]
path = "/opt/kata/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[shim.kata]
path = "/opt/kata/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
#enable_debug = true

# If enabled, the shim will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
#
# Note: By default, the shim runs in a separate network namespace. Therefore,
# to allow it to send trace details to the Jaeger agent running on the host,
# it is necessary to set 'disable_new_netns=true' so that it runs in the host
# network namespace.
#
# (default: disabled)
#enable_tracing = true

[agent.kata]
# If enabled, make the agent display debug-level messages.
# (default: disabled)
#enable_debug = true

# Enable agent tracing.
#
# If enabled, the default trace mode is "dynamic" and the
# default trace type is "isolated". The trace mode and type are set
# explicity with the `trace_type=` and `trace_mode=` options.
#
# Notes:
#
# - Tracing is ONLY enabled when `enable_tracing` is set: explicitly
#   setting `trace_mode=` and/or `trace_type=` without setting `enable_tracing`
#   will NOT activate agent tracing.
#
# - See https://github.com/kata-containers/agent/blob/master/TRACING.md for
#   full details.
#
# (default: disabled)
#enable_tracing = true
#
#trace_mode = "dynamic"
#trace_type = "isolated"

# Comma separated list of kernel modules and their parameters.
# These modules will be loaded in the guest kernel using modprobe(8).
# The following example can be used to load two kernel modules with parameters
#  - kernel_modules=["e1000e InterruptThrottleRate=3000,3000,3000 EEE=1", "i915 enable_ppgtt=0"]
# The first word is considered as the module name and the rest as its parameters.
# Container will not be started when:
#  * A kernel module is specified and the modprobe command is not installed in the guest
#    or it fails loading the module.
#  * The module is not available in the guest or it doesn't met the guest kernel
#    requirements, like architecture and version.
#
kernel_modules=[]


[netmon]
# If enabled, the network monitoring process gets started when the
# sandbox is created. This allows for the detection of some additional
# network being added to the existing network namespace, after the
# sandbox has been created.
# (default: disabled)
#enable_netmon = true

# Specify the path to the netmon binary.
path = "/opt/kata/libexec/kata-containers/kata-netmon"

# If enabled, netmon messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
#enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged (Deprecated)
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#     ***NOTE: This feature has been deprecated with plans to remove this
#     feature in the future. Please use other network models listed below.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
#
#   - none
#     Used when customize network. Only creates a tap device. No veth pair.
#
#   - tcfilter
#     Uses tc filter rules to redirect traffic from the network interface
#     provided by plugin to a tap interface connected to the VM.
#
internetworking_model="tcfilter"

# disable guest seccomp
# Determines whether container seccomp profiles are passed to the virtual
# machine and applied by the kata agent. If set to true, seccomp is not applied
# within the guest
# (default: true)
disable_guest_seccomp=true

# If enabled, the runtime will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
# (default: disabled)
#enable_tracing = true

# If enabled, the runtime will not create a network namespace for shim and hypervisor processes.
# This option may have some potential impacts to your host. It should only be used when you know what you're doing.
# `disable_new_netns` conflicts with `enable_netmon`
# `disable_new_netns` conflicts with `internetworking_model=bridged` and `internetworking_model=macvtap`. It works only
# with `internetworking_model=none`. The tap device will be in the host network namespace and can connect to a bridge
# (like OVS) directly.
# If you are using docker, `disable_new_netns` only works with `docker run --net=none`
# (default: false)
#disable_new_netns = true

# if enabled, the runtime will add all the kata processes inside one dedicated cgroup.
# The container cgroups in the host are not created, just one single cgroup per sandbox.
# The sandbox cgroup is not constrained by the runtime
# The runtime caller is free to restrict or collect cgroup stats of the overall Kata sandbox.
# The sandbox cgroup path is the parent cgroup of a container with the PodSandbox annotation.
# See: https://godoc.org/github.com/kata-containers/runtime/virtcontainers#ContainerType
sandbox_cgroup_only=false

# If enabled, the runtime will not create Kubernetes emptyDir mounts on the guest filesystem. Instead, emptyDir mounts will
# be created on the host and shared via 9p. This is far slower, but allows sharing of files from host to guest.
disable_guest_empty_dir = true

# Enabled experimental feature list, format: ["a", "b"].
# Experimental features are features not stable enough for production,
# They may break compatibility, and are prepared for a big version bump.
# Supported experimental features:
# 1. "newstore": new persist storage driver which breaks backward compatibility,
#                               expected to move out of experimental in 2.0.0.
# (default: [])
experimental=[]
vmss-agent-kata-vmss-test-jsuwk000002 bin # uname -r
4.19.106-flatcar
vmss-agent-kata-vmss-test-jsuwk000002 bin # cat /etc/os-release
NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=2345.3.0
VERSION_ID=2345.3.0
BUILD_ID=2020-02-29-1943
PRETTY_NAME="Flatcar Container Linux by Kinvolk 2345.3.0 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar-linux.org/"
BUG_REPORT_URL="https://issues.flatcar-linux.org"
FLATCAR_BOARD="amd64-usr"

evanfoster on 28 May 2020

@stefanha @amshinde there seems to be another issue with virtiofs. When trying larger file sizes, which can be easily reproduced with fio. I think it needs a seperate bug, but tagging it here for now.

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75"

We cannot complete the layout of the file

fio will hang at Laying out IO file (1 file / 4096MiB)

Increasing the virtiofs cache size does help. It is currently set to 4GB. Writing files smaller than 4GB works. 4GB and beyond does not work.

/cc @ganeshmaharaj @sboeuf

mcastelino on 25 Jun 2020

👀1

Were there any updates here @stefanha @mcastelino @ganeshmaharaj @amshinde ?

egernst on 29 Jul 2020

During some acceptance testing with the qemu5.0-virtiofs-dax branch of https://gitlab.com/virtio-fs/qemu.git, I found that virtiofs now performs better with a cache.

evanfoster on 2 Sep 2020

Runtime: Poor qemu-virtiofs performance in benchmarks

Description of problem

Expected result

Environment

Most helpful comment

All 15 comments

Related issues