6 Replies to “DragonFly on a VPS”

  1. Siju says:

    This is wonderful news and what I was waiting for!
    Wonder if the have a free tier where we could test the feasibility of mirroring from local to cloud VPS

  2. Mike says:

    Are there any news about the virtio-pci driver?

  3. Sascha Wildner says:

    What’s missing from our virtio-pci?

  4. Mike says:

    Speed – compared to linux.

  5. On the virtio front, bits of things that should be done for better performance:

    [virtio-pci]: The interrupt setup code should be reworked, to remove legacy MSI support (nonstandard for virtio) and enable MSI-X where possible; this should slightly improve interrupt performance by itself, should help a lot more when virtio-net support multiple RX/TX queues.

    [virtqueue/virtio core]: Restore indirect ring support — QEMU’s virtio-blk has a default 128-entry ring; virtio-blk can blow out that ring readily without indirect ring support. virtio-blk is often performance limited by this (in bandwidth).

    [virtio-blk]: Indirect ring entries; see above.

    [virtio-blk]: We investigated “pacing” a while back — while the isr is running on an ithread, the front end (dispatch) code can queue directly to it, rather than generating a VQ kick. It changed performance, mostly for the better when we played with it.

    [virtio-blk]: Investigate why DFly doesn’t (didn’t?) run on qemu when virtio-blk dataplane is enabled. It seemed to stall somewhere in the bootloader.

    [virtio-net]: Multiple TX/RX queues, one per CPU; DragonFly could make excellent use of this. One serializer per-queue. Looking at the differences between the if_em and if_emx driver would show the diffs required, roughly.

    Other stuff for running on KVM:
    PV-EOI — paravirt EOI should reduce the cost of ACKing a virtual interrupt, specifically the number of intercepts.

    kvmclock: Not sure what the default DFly timer is on KVM these days; kvmclock may be a better option than the ACPI-safe timer, the CMOS RTC, and the i8254.

    Dragonfly’s idle thread tries to use MONITOR/MWAIT for a bit before switching to HLT (and then deeper). In workloads with rapid halt/activate cycles, the early monitor/mwait helped a lot, but it is not available in KVM. Some other fast halt may be worth looking into, before dropping to a full HLT. (HLT may be fairly expensive in a VM).

  6. Anonymous says:

    For the record, I use virtio-net in all my virtual dfly instances, and it works amazingly well.

Comments are closed.