On 2017/6/22 19:50, Wanpeng Li wrote:
2017-06-22 19:22 GMT+08:00 root <yang.zhang.wz@xxxxxxxxx>:
From: Yang Zhang <yang.zhang.wz@xxxxxxxxx>
Some latency-intensive workload will see obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost i have seen is
inside idle path.
This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.
Here is the data i get when running benchmark contextswitch
(https://github.com/tsuna/contextswitch)
before patch:
2000000 process context switches in 4822613801ns (2411.3ns/ctxsw)
after patch:
2000000 process context switches in 3584098241ns (1792.0ns/ctxsw)
If you test this after disabling the adaptive halt-polling in kvm?
What's the performance data of w/ this patchset and w/o the adaptive
halt-polling in kvm, and w/o this patchset and w/ the adaptive
halt-polling in kvm? In addition, both linux and windows guests can
get benefit as we have already done this in kvm.
I will provide more data in next version. But it doesn't conflict with
current halt polling inside kvm. This is just another enhancement.
Regards,
Wanpeng Li
Yang Zhang (2):
x86/idle: add halt poll for halt idle
x86/idle: use dynamic halt poll
Documentation/sysctl/kernel.txt | 24 ++++++++++
arch/x86/include/asm/processor.h | 6 +++
arch/x86/kernel/apic/apic.c | 6 +++
arch/x86/kernel/apic/vector.c | 1 +
arch/x86/kernel/cpu/mcheck/mce_amd.c | 2 +
arch/x86/kernel/cpu/mcheck/therm_throt.c | 2 +
arch/x86/kernel/cpu/mcheck/threshold.c | 2 +
arch/x86/kernel/irq.c | 5 ++
arch/x86/kernel/irq_work.c | 2 +
arch/x86/kernel/process.c | 80 ++++++++++++++++++++++++++++++++
arch/x86/kernel/smp.c | 6 +++
include/linux/kernel.h | 5 ++
kernel/sched/idle.c | 3 ++
kernel/sysctl.c | 23 +++++++++
14 files changed, 167 insertions(+)
--
1.8.3.1
--
Yang
Alibaba Cloud Computing
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
