2017-03-14 21:27+0100, Radim Krčmář: > 2017-03-14 19:39+0100, Christoffer Dall: >> On Tue, Mar 14, 2017 at 05:58:59PM +0100, Radim Krčmář wrote: >>> 2017-03-14 09:26+0100, Christoffer Dall: >>> > On Mon, Mar 13, 2017 at 06:28:16PM +0100, Radim Krčmář wrote: >>> >> 2017-03-08 02:57-0800, Christoffer Dall: >>> >> > Hi Paolo, >>> >> > >>> >> > I'm looking at improving KVM/ARM a bit by calling guest_exit_irqoff >>> >> > before enabling interrupts when coming back from the guest. >>> >> > >>> >> > Unfortunately, this appears to mess up my view of CPU usage using >>> >> > something like htop on the host, because it appears all time is spent >>> >> > inside the kernel. >>> >> > >>> >> > From my analysis, I think this is because we never handle any interrupts >>> >> > before enabling interrupts, where the x86 code does its >>> >> > handle_external_intr, and the result on ARM is that we never increment >>> >> > jiffies before doing the vtime accounting. >>> >> >>> >> (Hm, the counting might be broken on nohz_full then.) >>> >> >>> > >>> > Don't you still have a scheduler tick even with nohz_full and something >>> > that will eventually update jiffies then? >>> >>> Probably, I don't understand jiffies accounting too well and didn't see >>> anything that would bump the jiffies in or before guest_exit_irqoff(). >> >> As far as I understand, from my very very short time of looking at the >> timer code, jiffies are updated on every tick, which can be cause by a >> number of events, including *any* interrupt handler (coming from idle >> state), soft timers, timer interrupts, and possibly other things. > > Yes, I was thinking that entering/exiting user mode should trigger it as > well, in order to correctly account for time spent there, but couldn't > find it ... > > The case I was wondering about is if the kernel spent e.g. 10 jiffies in > guest mode and then exited on mmio -- no interrupt in the host, and > guest_exit_irqoff() would flip accouting would over system time. > Can those 10 jiffies get accounted to system (not guest) time? > > Accounting 1 jiffy wrong is normal as we expect that the distribution of > guest/kernel time in the jiffy is going to be approximated over a longer > sampling period, but if we could account multiple jiffies wrong, this > expectation is very hard to defend. IIUC, other CPU will bump jiffies of running tickless VCPUs, so this works fine.