On Tue, May 24, 2016 at 9:23 AM, Yang Zhang <yang.zhang.wz@xxxxxxxxx> wrote: > On 2016/5/23 22:18, Paolo Bonzini wrote: >> >> >> >> On 23/05/2016 03:34, Yang Zhang wrote: >>> >>> On 2016/5/20 14:38, Denis V. Lunev wrote: >>>> >>>> On 05/20/2016 04:15 AM, Yang Zhang wrote: >>>>> >>>>> On 2016/5/19 13:40, Denis V. Lunev wrote: >>>>>> >>>>>> On 05/19/2016 05:01 AM, Yang Zhang wrote: >>>>>>> >>>>>>> On 2016/5/18 22:48, Roman Kagan wrote: >>>>>>>> >>>>>>>> The function to update APICv on/off state (in particular, to >>>>>>>> deactivate >>>>>>>> it when enabling Hyper-V SynIC), used to be incomplete: it didn't >>>>>>>> adjust >>>>>>>> APICv-related fields among secondary processor-based VM-execution >>>>>>>> controls. >>>>>>> >>>>>>> Roman, >>>>>>> >>>>>>> I have question about the performance between APICv and Hyper-V >>>>>>> SynIC. >>>>>>> As we known APICv is a hardware feature which including three >>>>>>> features: APIC register virtualization, virtual interrupt delivery >>>>>>> and >>>>>>> Posted Interrupt. My gut feeling is that the average performance that >>>>>>> improved by APICv should greater than Hyper-v SynIC. Am i right? If >>>>>>> yes, current policy that disable the whole APICv seems too >>>>>>> aggressive. >>>>>>> >>>>>> Argh.. We have faced this situation in Parallels Desktop may be >>>>>> 3 years ago. Unfortunately, there is no data at the moment. >>>>>> It was toooo old and made by other team. As far as I remember >>>>>> (for that time), interrupt delivery becomes faster, but operations >>>>>> with on of CR registers becomes much slower and general >>>>>> performance score becomes lower. >>>>> >>>>> >>>>> I guess the data may be collected on KVM w/o APICv supporting. >>>>> Normally, APICv provides the faster way to delivery interrupt than >>>>> software solution. >>>>> >>>> this seems useless. >>>> >>>> Once again, interrupt delivery with APICv will be faster, >>>> this is out of question. Though integral tests can show >>>> performance degradation. I know, this sounds silly >>>> and this is test-dependent. >>>> >>>> We are going to make this testing after implementing >>>> of HyperV TSC page avoid extra VM exit on context >>>> switch. This seems more beneficial at the moment. >>>> >>>> For this reason APICv is disabled in Parallels Desktop >>>> and Parallels Server v6, which are not KVM based. >>>> >>>>>> >>>>>> The problem with SynIC is that it is mandatory prerequisite >>>>>> to enable HyperV bus in the guest, which is our final goal. >>>>>> Thus there is no other way for us. >>>>> >>>>> >>>>> I see. Actually, we saw the performance improvement with SynIC timer >>>>> but we don't want to turn off APICv since we think it may hurt the >>>>> performance. Is it possible to turn on SynIC timer without disable >>>>> APICv? >>>>> >>>> unfortunately no. The problem is AutoEOI feature. At >>>> least we have no idea how to do that. >>> >>> >>> Ok. Thanks for your explanation. >> >> >> You can search the KVM mailing list archives; there are some discussions >> between me, Andrey and Roman regarding APICv---when I tried their unit >> tests on a Haswell-EP machine I found that they broke due to AutoEOI, >> and we came up with the solution of disabling APICv. > > > Thanks. I will check it. > >> >> For what it's worth, we've also seen only very small performance >> improvements from APICv, with the exception of nested virtualization >> where APICv's impact is large. > > > I think it depends on the workload. For some micro benchmarks, we have see > more than 10% improvement, like ping latency testing. But for normal > workload, you may only seen less than 2% improvement. > APICv does have a big improvement for windows guest with some scenario. One of our customers use Windows Server 2008 R2 to run a game server, there are many small TCP packets transferring between the server and client. The server side use kernel spin-lock frequently, NT kernel is different with Linux, it will raise TPR to 2 if a spin-lock accquired. We also see that the context switch rate on HOST is very high w/o APICv, and GUEST ping will raise up to ~2000ms, even lost network respond. I think the frequently _tpr_below_threshold_ and the _irq_window_ vmexits slow down the GUEST, and the interrupt of guest will have a huge latency. With APICv, the guest will run normally. Thanks, Wincy -- 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
