That’s Virtual Private Server, if you don’t know the term. I mentioned VPSs and BSD before in a In Other BSDs article, but “Ed” found an article specifically about installing DragonFly on Vultr.
6 Replies to “DragonFly on a VPS”
Comments are closed.
A running description of activity related to DragonFly BSD.
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
Are there any news about the virtio-pci driver?
What’s missing from our virtio-pci?
Speed – compared to linux.
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).
For the record, I use virtio-net in all my virtual dfly instances, and it works amazingly well.