David S. Ahern wrote:
> David S. Ahern wrote:
>
>> Avi Kivity wrote:
>>
>>
>>> David S. Ahern wrote:
>>>
>>>
>>>> I added the traces and captured data over another apparent lockup of
>>>> the guest.
>>>> This seems to be representative of the sequence (pid/vcpu removed).
>>>>
>>>> (+4776) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>>>> c016127c ]
>>>> (+ 0) PAGE_FAULT [ errorcode = 0x00000003, virt = 0x00000000
>>>> c0009db4 ]
>>>> (+3632) VMENTRY
>>>> (+4552) VMEXIT [ exitcode = 0x00000000, rip = 0x00000000
>>>> c016104a ]
>>>> (+ 0) PAGE_FAULT [ errorcode = 0x0000000b, virt = 0x00000000
>>>> fffb61c8 ]
>>>> (+ 54928) VMENTRY
>>>>
>>>>
>>> Can you oprofile the host to see where the 54K cycles are spent?
>>>
>>>
>
> Most of the cycles (~80% of that 54k+) are spent in paging64_prefetch_page():
>
> for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
> gpa_t pte_gpa = gfn_to_gpa(sp->gfn);
> pte_gpa += (i+offset) * sizeof(pt_element_t);
>
> r = kvm_read_guest_atomic(vcpu->kvm, pte_gpa, &pt,
> sizeof(pt_element_t));
> if (r || is_present_pte(pt))
> sp->spt[i] = shadow_trap_nonpresent_pte;
> else
> sp->spt[i] = shadow_notrap_nonpresent_pte;
> }
>
> This loop is run 512 times and takes a total of ~45k cycles, or ~88 cycles per
> loop.
>
> This function gets run >20,000/sec during some of the kscand loops.
>
>
We really ought to optimize it. That's second order however. The real
fix is making sure it isn't called so often.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
