On 10/12/2014 18:34, Marcelo Tosatti wrote: >> > Let's start with a kvm-unit-tests patch to measure this value. > I can, but kvm-unit-test register state will not be similar to > actual guest state (think host/guest state loading). 7us is about 20000 clock cycles. A lightweight vmexit is an order of magnitude less expensive, and half of the vmexit overhead is the VMRUN instruction itself. All in all, the host/guest state loading should not matter (or should matter little). > What is the advantage of using a kvm-unit-test test rather > than cyclictest in the guest ? That it starts in <3 seconds, and that you can vary the timer frequency in order to measure jitter in addition to latency. >> We can then decide whether to hardcode a small default value (e.g. >> 1000-3000) and make it a module parameter? Or perhaps start with a >> higher value (twice what you find in practice?) and adjust it towards a >> target every time wait_lapic_expire is called. But in order to judge >> the correct approach, I need to see the numbers. > > Problem with automatic adjustment is: what is the correct target? We cannot say without seeing the numbers, particularly the jitter. This is why I want to see numbers for varying frequencies (from 100us to 10ms per tick, say). > You want faster instances of apic_timer_fn->vm-entry to spin a bit, > and allow slow instances of apic_timer_fn->vm-entry to have > an effective advancement. If it is small enogh, you can make the timer a little "early" (increase advance) by a small amount on every delivered interrupt. This prepares for a slow instance. And you can make the timer less "early" (decrease advance) by some percentage of what you had to wait on every wait_lapic_expire, if you had to wait more than a given threshold. This avoids that you wait too much on consecutive fast instances. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
