On 2023/05/27 15:35, Mike Larkin wrote: > On Sat, May 27, 2023 at 10:29:37AM +0200, Claudio Jeker wrote: > > On Sat, May 27, 2023 at 09:16:23AM +0100, Stuart Henderson wrote: > > > On 2023/05/27 06:36, br...@mailbox.org wrote: > > > > > > > > > > > > On Sat, 27 May 2023, Mike Larkin wrote: > > > > > > > > > probably IPI traffic then. not sure what else to say. If a few % host > > > > > overhead > > > > > is too much fot you with a 16 vCPU VM, I'd suggest reducing that. > > > > > > > > > > What is your workload for a 16 vcpu openbsd VM anyway? > > > > > > > > I would like to use the OpenBSD VM as my main workstation. I also need > > > > to > > > > use Linux for some graphic intensive stuff, so the ideal OpenBSD on host > > > > with vmm for Linux is not an option unfortunately. I guess I could > > > > accept > > > > that CPU usage price, but of course not having to pay it would be > > > > better. > > > > > > OpenBSD doesn't do brilliantly with that many CPUs yet. Things are > > > getting better but I think you're likely to find many workloads are a > > > bit less laggy with half that. > > > > Also a few % CPU on the host can be caused by the interrupts caused by the > > clocks on every CPU. It may be that we do not select a cheap clock source > > like TSC and the result is much more overhead on the host. > > > > -- > > :wq Claudio > > > > yes I did not think of that; thanks Claudio! > > OP: what is your sysctl kern.timecounter ?
on kvm I would expect pvclock to be preferred if the driver thinks it's stable, otherwise probably acpihpet. fwiw mine looks like this. $ sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=acpihpet0 kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) acpitimer0(1000)
