Re: VirtIO vs Emulation Netperf benchmark results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/10/12 10:55, Alexander Graf wrote:
> 
> 
> On 11.10.2012, at 11:46, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>>
>> - Our exit path is painfully long. We could maybe make it more efficient
>> by being more lazy, and delay the switch of some of the state until we
>> get preempted (VFP state, for example). Not sure how much of an
>> improvement this would make, though.
> 
> Lazy FP switch bought me quize a significant speedup on ppc. It won't help you here though. User space exits need to restore that state regardless. Unless the guest hasn't used FP. Then you can save yourself both ways of FP state switches.

Depends how often we exit all the way to userspace. And even then,
moving the (already lazy) VFP restore to the preempt handler is likely
to be a gain if you manage to do more than a single entry/exit before
being preempted or returning to userspace.

>>
>> - Our memory bandwidth is reduced by the number of TLB entries we waste
>> by not using section mappings instead of 4kB pages. Running hackbench on
>> a guest shows quite a slowdown that should mostly go away if/when
>> userspace switches to huge pages as backing store. I expect virtio to
>> suffer from the same problem.
> 
> That one should be in a completely different ballpark. I'd be very surprised if you get more than 10% slowdowns in TLB miss intensive workloads. Definitely not as low of a hanging fruit as we see here.

I see about 40% degradation in hackbench when running in a VM (that's
from my recollection of the timings, I could run it an get you some hard
numbers).

The A15 uses separate TLBs for stage-1 and stage-2 translation, which
means that each random memory access costs us two TLBs, effectively
reducing the efficiency of the translation hardware by 50%.

Using 2MB sections as the backing store (stage-2) should definitely be a
quite an improvement.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux