Hi, I don't see this issue on my Debian system, but please try two things:
* disable kvm_intel.preemption_timer on the host (see /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in linux 4.10 and newer * enable hpet in the vm config: Make sure there is no <timer name='hpet' present='no'/> in your libvirt xml (or don't pass -ho-hpet to qemu). Unfortunately, newer libvirt versions seem to disable hpet by default. Different issue: If you remove the USB controllers, the CPU load on the host will reduce by a few percent (~ 3%). Add <controller type='usb' index='0' model='none'/> and remove all other usb controller sections. Just removing the usb controller sections without adding the 'none' makes libvirt add them back (this is stupid). Cheers, Stefan On Fri, 12 Jan 2018, Infoomatic wrote: > Same problem here. While we did have significant differences in cpu > usage between FreeBSD and OpenBSD (basic OS without configuration: > FreeBSD ~ 33min CPU time, OpenBSD ~ 474min CPU time - both started at > the same time), with the latest kernel patches for Ubuntu 17.04 (our > test environments all run Ubuntu 17.04 for KVM VMs), OpenBSD now becomes > practically unusable: as soon as I su or login on the console with su, > cpu usage is at 100% - the system freezes. :-/ guess we need some > dedicated BSD machines to host some test-VMs ;-) > > Regards, > Robert > > > > Gesendet: Donnerstag, 11. Januar 2018 um 20:32 Uhr > > Von: "Kirill Miazine" <k...@krot.org> > > An: misc@openbsd.org > > Betreff: Re: Performance issues as KVM guest? > > > > * Kent Watsen [2018-01-11 17:38]: > > [...] > > > > > Since my hosting provider https://www.bytemark.co.uk/cloud-hosting/ > > > > > patched for Meltdown last weekend I'm seeing significant performance > > > > > issues with an OpenBSD virtual instance there. It seems okay after a > > > > > fresh reboot but then progressively returns to being very slow: for > > > > > example "sleep 1" may take four seconds, then five, six, seven, then > > > > > rather more. Curiously it does tend to be an integral multiplier. > > > > > > > > > > I wondered, is anybody else seeing significant performance problems > > > > > with > > > > > OpenBSD (or other BSDs) virtual instances since Meltdown patching? Is > > > > > there anything to tweak at my end or am I reliant on the provider? > > > > > > > > > > -- Mark > > > > > > > > > There are a ton of threads talking about this issue, and it's not > > > > meltdown > > > > specific. Please search the archives. > > > > > > > > -ml > > > > > > [...] > > > Also, Mark, could you say some more about the issue. For instance, how > > > long > > > after a reboot does it take until you start to notice the issue, and how > > > quickly does it get worse? > > > > I'm another customer of Bytemark experiencing the same issue. I'm taking > > care of one VM there and I'm primarly noticing it in two situations: > > sleep() takes a long time (e.g. sleep(1) might take up to 40 seconds) > > and the clock slows down. > > > > Right now, 9 hours after reboot, the clock on VM is 3 hours behind real > > clock. And sleep(1) takes 13 secs: > > > > km@buildfarm ~ $ time sleep 1 > > 0m13.85s real 0m00.00s user 0m00.01s system > > > > This all started after the host was patched and VM rebooted. > > > > Bytemark guys are looking at the issue and doing their own debugging. > > Here're findings so far: > > > > I spun a few OpenBSD VMs up and left them overnight - looks like the > > clock isn't drifting but there's still the 'time sleep 1' issue. > > My testing results seemed to concur with User_4574's, virtio was slowing > > down only a few minutes after a fresh install whereas compatibility > > would stick at 1s, jump to 2s, etc. > > > > > > > > Thanks, > > > Kent > > > > > > > -- > > -- Kirill Miazine <k...@krot.org> > > > > > >
