Avi Kivity wrote:
>>> These numbers are pretty bad. I'd like to improve them, even
>>> without PV.
>>
>> I agree. Do you know what's missing at this point? There isn't a
>> whole lot of state saving going on for the light weight exit paths
>> for SVM.
>
> The SVM code doesn't even have a lightweight vmexit path.
Sure it does. Quite a lot is deferred to vcpu_{load,put}.
> For every vmexit, it does the entire thing, including vmload/vmsave
I haven't had a lot of luck eliminating vmload/vmsave.
> , fpu switch (if needed)
The FPU switch can really be avoided? Is it safe to assume that the KVM
code isn't going to use any FPU operations?
> , segment reloading, and msr reloading.
Yeah, the VMX path is doing some clever things there. A fair bit more
could be deferred on SVM.
> It could use a lot of work.
>
> For kbuild vs. kernbench, I suspect that -j4 causes the shadow page
> table cache to thrash. 1024 pages may be enough for a single instance
> but not -j4. Hopefully replacing the eviction algorithm (currently
> FIFO) will help. Otherwise we'll need to resize the cache again.
I naively tried to bump it to 2048 and hit a kmalloc limitation.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
