On 2016/5/24 9:16, David Matlack wrote:
On Mon, May 23, 2016 at 6:13 PM, Yang Zhang <yang.zhang.wz@xxxxxxxxx> wrote:
On 2016/5/24 2:04, David Matlack wrote:
On Sun, May 22, 2016 at 6:26 PM, Yang Zhang <yang.zhang.wz@xxxxxxxxx>
wrote:
On 2016/5/21 2:37, David Matlack wrote:
It's not obvious to me why polling for a timer interrupt would improve
context switch latency. Can you explain a bit more?
We have a workload which using high resolution timer(less than 1ms)
inside
guest. It rely on the timer to wakeup itself. Sometimes the timer is
expected to fired just after the VCPU is blocked due to execute halt
instruction. But the thread who is running in the CPU will turn off the
hardware interrupt for long time due to disk access. This will cause the
timer interrupt been blocked until the interrupt is re-open.
Does this happen on the idle thread (swapper)? If not, halt-polling
may not help; it only polls if there are no other runnable threads.
Yes, there is no runnable task inside guest.
Sorry for the confusion, my question was about the host, not the
guest. Halt-polling only polls if there are no other runnable threads
on the host CPU (see the check for single_task_running() in
kvm_vcpu_block()).
ok, i see your point. I didn't check it before. But i have observed that
the host CPU may wake up immediately after entering the power idle. Then
another task takes the CPU until the schedule signal arrived. And this
will cause timer injection delay by several ms.
For optimization, we let VCPU to poll for a while if the next timer will
arrive soon before schedule out. And the result shows good when running
several workloads inside guest.
Thanks for the explanation, I appreciate it.
--
best regards
yang
--
best regards
yang
--
best regards
yang
--
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
