Avi Kivity wrote:
> Anthony Liguori wrote:
>> 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}.
>
> Ah, I forgot. Yes, the syscall msrs are deferred.
>
>>
>>> For every vmexit, it does the entire thing, including vmload/vmsave
>>
>> I haven't had a lot of luck eliminating vmload/vmsave.
>>
>
> For x86_64, the only issue I see is with TR. Unfortunately, I don't
> see a way around it.
>
>
>>> , 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?
>
> Generally, kernel code does not use the fpu (when it does, it calls
> kernel_fpu_begin() and kernel_fpu_end()). The vmx code avoids the
> switch.
>
> Of course, if the guest doesn't use the fpu, the switch is avoided
> anyway.
>
>>>
>>> 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.
>>
>
> struct kvm is 22K on x86_64. Adding 1024 pointers makes it 30K. What
> error did you get?
With an older kvm, on a different system, I was getting:
WARNING: "__you_cannot_kzalloc_that_much"
On the latest git though, I don't seem to get that warning on my
development system even if I bump all the way up to 8192. I'll see what
bumping to 2048 does to kernbench. 4MB is actually small compared to
other hypervisors for a shadow page table cache (Xen defaults to 8mb) so
we may see good results.
Regards,
Anthony Liguori
> We should probably make the hashtable a pointer, and allocate vcpus
> separately as well.
>
-------------------------------------------------------------------------
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
