On 2017/9/14 17:19, Wanpeng Li wrote:
2017-09-14 16:36 GMT+08:00 Quan Xu <quan.xu0@xxxxxxxxx>:
on 2017/9/13 19:56, Yang Zhang wrote:
On 2017/8/29 22:56, Michael S. Tsirkin wrote:
On Tue, Aug 29, 2017 at 11:46:34AM +0000, Yang Zhang wrote:
Some latency-intensive workload will see obviously performance
drop when running inside VM.
But are we trading a lot of CPU for a bit of lower latency?
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.
Isn't it the job of an idle driver to find the best way to
halt the CPU?
It looks like just by adding a cstate we can make it
halt at higher latencies only. And at lower latencies,
if it's doing a good job we can hopefully use mwait to
stop the CPU.
In fact I have been experimenting with exactly that.
Some initial results are encouraging but I could use help
with testing and especially tuning. If you can help
pls let me know!
Quan, Can you help to test it and give result? Thanks.
Hi, MST
I have tested the patch "intel_idle: add pv cstates when running on kvm" on
a recent host that allows guests
to execute mwait without an exit. also I have tested our patch "[RFC PATCH
v2 0/7] x86/idle: add halt poll support",
upstream linux, and idle=poll.
the following is the result (which seems better than ever berfore, as I ran
test case on a more powerful machine):
for __netperf__, the first column is trans. rate per sec, the second column
is CPU utilzation.
1. upstream linux
This "upstream linux" means that disables the kvm adaptive
halt-polling after confirm with Xu Quan.
upstream linux -- the source code is just from upstream linux, without
our patch or MST's patch..
yes, we disable kvm halt-polling(halt_poll_ns=0) for _all_of_ following
cases.
Quan
Regards,
Wanpeng Li
28371.7 bits/s -- 76.6 %CPU
2. idle=poll
34372 bit/s -- 999.3 %CPU
3. "[RFC PATCH v2 0/7] x86/idle: add halt poll support", with different
values of parameter 'halt_poll_threshold':
28362.7 bits/s -- 74.7 %CPU (halt_poll_threshold=10000)
32949.5 bits/s -- 82.5 %CPU (halt_poll_threshold=20000)
39717.9 bits/s -- 104.1 %CPU (halt_poll_threshold=30000)
40137.9 bits/s -- 104.4 %CPU (halt_poll_threshold=40000)
40079.8 bits/s -- 105.6 %CPU (halt_poll_threshold=50000)
4. "intel_idle: add pv cstates when running on kvm"
33041.8 bits/s -- 999.4 %CPU
for __ctxsw__, the first column is the time per process context switches,
the second column is CPU utilzation..
1. upstream linux
3624.19 ns/ctxsw -- 191.9 %CPU
2. idle=poll
3419.66 ns/ctxsw -- 999.2 %CPU
3. "[RFC PATCH v2 0/7] x86/idle: add halt poll support", with different
values of parameter 'halt_poll_threshold':
1123.40 ns/ctxsw -- 199.6 %CPU (halt_poll_threshold=10000)
1127.38 ns/ctxsw -- 199.7 %CPU (halt_poll_threshold=20000)
1113.58 ns/ctxsw -- 199.6 %CPU (halt_poll_threshold=30000)
1117.12 ns/ctxsw -- 199.6 %CPU (halt_poll_threshold=40000)
1121.62 ns/ctxsw -- 199.6 %CPU (halt_poll_threshold=50000)
4. "intel_idle: add pv cstates when running on kvm"
3427.59 ns/ctxsw -- 999.4 %CPU
-Quan
--
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
