bhyve issues on Dell C6220 node

Matt Churchyard matt.churchyard at userve.net
Tue Jan 14 10:40:52 UTC 2020


> Hi,

> >2016 is slow (even slower doing windows updates).  2019 is much better.  A tip I have found is a minimum of 1 cpu, 2 cores and 4 threads to get decent speed from that OS (more CPUs in bhyve >tends to make performance worse - in my observations - in 2016).  Also, use the Virtio collection from RedHat for vionet and viostor.  We are currently using 0.1.171 without issue.  The ahci >emulation in itself is extremely slow.  NVMe and virtio is really the only way to go.
> 
> Is there anything else I can check here? I haven’t got round to testing networking yet but I’m using nvme for the disk.
> It’s basically unusable and there is no way I could put anything production on it. Just highlighting an icon on the desktop takes several seconds.

>Windows is slow when running on Intel CPUs that don't support APICv.
>That are (nearly?) all desktop CPUs, all Xeons before Sandy Bridge and some Xeons after it. The problem is that Bhyve doesn't implement TPR shadowing. I'm currently working on it. The review can >be found
>here: https://reviews.freebsd.org/D22942 The speedup is about factor 6!

>I've received some feedback in a private mail, a second version that adds TPR thresholds can be found in my Github branch here:
>  https://github.com/Yamagi/freebsd/commits/wip/tpr_shadowing 

>A backport to 12.1 (the branch also includes the Intel SpeedShift patches from https://reviews.freebsd.org/D18028) is here:
>https://github.com/Yamagi/freebsd/commits/production/12.1

>I've applied it to 2 of my production servers about 4 hours ago. Looks good so far. I'll update the review when I'm sure that it doesn't break anything, maybe early next week.

I've been running the patch for a few days now and not seen any problems. It's a complete difference compared to running stock 12.1.
Thanks for your response and awesome work.

Don't know if any more work on it is required but it would be nice if this made it into 12.2 as it's much easier for me to track the binary releases than have to rebuild the entire system. This fairly small patch makes a massive difference to Windows performance on something that doesn't have APICv

I also found the fix for my original console issue (actually someone else fixed it, I just hadn't seen their pull request). I'm using vm-bhyve which originally redirected bhyve output to a log file to catch any error output. Changes to the way bhyve opens stdin & stderr caused this to stop working correctly.

Regards,
Matt

>Regards,
>Yamagi

--
Homepage: https://www.yamagi.org
Github:   https://github.com/yamagi
GPG:      0x1D502515


More information about the freebsd-virtualization mailing list