On 24/04/2015 09:46, Zhang, Yang Z wrote:
On the other hand vmexit is lighter and lighter on newer processors; a
Sandy Bridge has less than half the vmexit cost of a Core 2 (IIRC 1000
vs. 2500 clock cycles approximately).
1000 cycles? I remember it takes about 4000 cycle even in HSW
Paolo Bonzini wrote on 2015-04-24:
On 24/04/2015 09:46, Zhang, Yang Z wrote:
On the other hand vmexit is lighter and lighter on newer
processors; a Sandy Bridge has less than half the vmexit cost of a
Core 2 (IIRC
1000 vs. 2500 clock cycles approximately).
1000 cycles? I remember it
On 24/04/2015 03:16, Zhang, Yang Z wrote:
This is interesting since previous measurements on KVM have had
the exact opposite results. I think we need to understand this a
lot more.
What I can tell is that vmexit is heavy. So it is reasonable to see
the improvement under some cases,
Paolo Bonzini wrote on 2015-04-24:
On 24/04/2015 03:16, Zhang, Yang Z wrote:
This is interesting since previous measurements on KVM have had the
exact opposite results. I think we need to understand this a lot
more.
What I can tell is that vmexit is heavy. So it is reasonable to see
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On 04/23/2015 08:28 AM, Dave Hansen wrote:
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
This is interesting since previous
H. Peter Anvin wrote on 2015-04-24:
On 04/23/2015 08:28 AM, Dave Hansen wrote:
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU is
about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
On 23/04/2015 23:13, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Signed-off-by: Liang
On 2015-04-23 12:40, Paolo Bonzini wrote:
On 23/04/2015 23:13, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4%
Cc Rik, who is doing the similar work. :)
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
On 04/23/2015 06:57 PM, Wanpeng Li wrote:
Cc Rik, who is doing the similar work. :)
Hi Liang,
I posted this patch earlier, which should have the same effect as
your patch on more modern systems, while not loading the FPU context
for guests that barely use it on older systems:
12 matches
Mail list logo
