On Thu, Sep 11, 2008 at 2:26 PM, Gianluca Guida
> 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.
Xen-devel mailing list