| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Fix performance issue brought by TSC-sync logic
Keir Fraser wrote:
On 23/02/2009 00:21, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx> wrote:
Recently we found one performance bug when doing network test with VTd
assigned devices - in some extreme case, the network performance in HVM
using new Linux kernel could be 1/20 of native. Root cause is one of our
sync-tsc-under-deep-C-state patches brings extra kilo-TSC drift between
pCPUs and let check-tsc-sync logic in HVM failed. The result is the
kernel fails to use platform timer (HPET, PMtimer) for gettimeofday
instead of TSC and brings very frequent costly IOport access VMExit -
triple per one call.
We provides below 2 patches to address the issue:
Patch 1 looks reasonable. Patch number 2 I'm less keen on, since patch 1
should suffice? Also I think regular re-sync across CPUs is a good idea
anyway.
Here is average of 100 cycles skew results on one core 2 quad machine:
1) TSC-sync: 1300
2) TSC-sync+tsc1.patch: 400
3) without TSC-sync: 200 (a.k.a sync at boot time only)
We can see from 1) to 2), cycles skew improves a lot. However Linux
kernel's logic to check TSC sync (check_tsc_warp) is very strict, so
even with tsc1.patch, there are still chances to observe checking failed
inside VM.
For further improvement to reach the effect of 3), e.g. by taking care
of cache consistance amongs CPUs, there will be more overhead. And
considering the function is called per second, we are hesitating to do
this. What's your idea?:)
Thanks,
xiaowei
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home