Anthony Liguori wrote: > Avi Kivity wrote: >>> And I would like to ask right and wrong to >>> implement the functionality in terms of need >>> and efficiency (scalability and time accuracy). >>> >> >> I think that for newer kernels we already have the desired accuracy. >> We're not always good at exploiting that accuracy; hence the recent >> movement of the PIT implementation from userspace to the kernel. But >> recent discussion leads me to believe it could have been implemented >> with the userspace PIT as well. >> > > What do you think is needed to get the same accuracy in userspace as > in kernelspace?
Some mechanism that allows us to implement kvm_inject_pit_timer_irqs() and kvm_pit_timer_intr_post(). Specifically, information about whether an interrupt was actually processed, and a window for injecting missed ticks. > Better yet, do you think there is a reasonable kvmctl harness we could > write to quantify the PIT accuracy? kvmctl doesn't implement a pit, so no. Of course we can test any infrastructure for counting missed interrupts. > > It's easy enough to count timer interrupts and use compare that to an > external time source to get some notion of accuracy (on varying > frequencies of course). I know you mentioned before that guest CPU > consumption also comes into play... I'm not quite sure why though so > I'm not sure how to simulate that. It's not so easy, the code is quite tricky since the cpu processes vectors, not interrupt lines. It's also heuristic; if the guest programs some random device to share interrupts with the pit, the heursitic breaks down. This never happens in practice, though. Problems show up when both the guest and host are loaded, as then the cpu is timesliced instead of being available on demand. > > The nice thing about the CAP infrastructure is we can always move the > PIT back to userspace. I'll happily invest some cycles here as I'm a > big fan of getting rid of unneeded kernel code :-) Yes. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
