|Priority:||4 - Normal|
|Created by:||John Levon [X]|
|Reported by:||John Levon [X]|
|Assigned to:||Patrick Mooney [X]|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-06-19T14:55:19.001Z)
2018-06-21 Underwater Reactor (Release Date: 2018-06-21)
A bunch of IPI traffic was noticed during dtrace an OpenBSD guest (after a boot -d), set up as per OS-6839:
2 85373 ipi_cpu:entry vmm`vcpu_notify_event_locked+0x6d vmm`vcpu_notify_event+0x4b vmm`vm_inject_extint+0x33 vmm`vlapic_fire_lvt+0x9b vmm`vlapic_trigger_lvt+0x98 vmm`lapic_set_local_intr+0x79 vmm`vatpic_notify_intr+0xb6 vmm`vatpic_set_pinstate+0xc0 vmm`vatpic_set_irqstate+0xb5 vmm`vatpic_pulse_irq+0x1a vmm`vatpit_callout_handler+0x6b vmm`vmm_glue_callout_handler+0x2f genunix`cyclic_softint+0xfd unix`cbe_low_level+0x14 unix`av_dispatch_softvect+0x78 apix`apix_dispatch_softint+0x35 unix`switch_sp_and_call+0x13
OS-6759 did not add a
cyclic_move_here() for vatpic's three cyclics, hence we are getting xcall traffic on the PIT timer.
It's not clear that this is really a problem: it's hard to think that a high-perf OS would carry on using the old-style PIT, and that has to be balanced against moving 3 cyclics on every
Indeed, a test boot of Linux at least shows PIT traffic only during the boot process.
If we do decide we want this, we could maybe gate it on a measure of PIT traffic in the last X seconds?
illumos-joyent commit 4f723dcffd015c7d11cd1c7a3155f46aa0600646 (branch master, by Patrick Mooney)
OS-6923 bhyve could be more precise with vPIT
OS-6849 bhyve should localize vatpit resources
Reviewed by: Hans Rosenfeld <firstname.lastname@example.org>
Reviewed by: Dan McDonald <email@example.com>
Approved by: Dan McDonald <firstname.lastname@example.org>