Re: [Xen-devel] Re: Poor performance on HVM (kernbench)

["Todd Deshane" <deshantm@xxxxxxxxx>]

On Thu, Sep 11, 2008 at 2:26 PM, Gianluca Guida
<gianluca.guida@xxxxxxxxxxxxx> wrote:
> George Dunlap wrote:
>>
>> So, the problem appears to be with a ton of brute-force searches to
>> remove writable mappings, both during resync and promotion.  My
>> analysis tool is reporting that of the 30 seconds or so in the trace
>> from xen-unstable, the guest spent a whopping 67% in the hypervisor:
>>  * 26% doing resyncs as a result of marking another page out-of-sync
>>  * 9% promoting pages
>>  * 27% resyncing as a result of cr3 switches
>> And almost the entirety of all of those can be attributed to
>> brute-force searches to remove writable mappings.
>
> Fantastic (well, sort of)!
>
> If I understand it correctly, Todd is using PV drivers in Linux HVM guests,
> so the reason for brute-force search is due to former L1 page-tables being
> used as I/O pages, not being unshadowed because they can get writable
> mappings out of it.
> It is, shortly, an unshadowing problem. Should be `easy` to fix. I wasn't
> using PV drivers, so I was not experiencing this behaviour.
>
> Or, it could be a fixup table bug, but I doubt it.
>
> George, did you saw excessive fixup faults in the trace?
>
> Todd, could you try without PV drivers (plain qemu emulation) and see if the
> results get better?

To the best of my knowledge, I am not using PV on HVM drivers since
they are not upstream.
I am using 2.6.27-rc4 xen domU kernel, with the normal xen PV drivers
and KVM virtio built in.
Am I mistaken?

I am running the test with shadow3 disabled now.
I'll report the results when they come out.

Any other suggestions or things for me to try, let me know.

Cheers,
Todd

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel