[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Poor performance on HVM (kernbench)
Ah, that's the problem... Linux seems to have changed the location of the 1:1 map. Gianluca's using an older kernel, where it's at 0xffff810000000000, but this trace has it at 0xffff880000000000, so the "guess" heuristic is missing. Jereme, is this a permanent long-term move, or is it going to be something random? I.e., should we just add a new heuristic "guess" at this address, or do we need to do something more complicated? That will solve brute-force searched for promotions, but the fixup table for out-of-sync mappings should still be fixed... -George On Fri, Sep 12, 2008 at 12:04 PM, George Dunlap <dunlapg@xxxxxxxxx> wrote: > On Thu, Sep 11, 2008 at 7:26 PM, Gianluca Guida > <gianluca.guida@xxxxxxxxxxxxx> wrote: >> Or, it could be a fixup table bug, but I doubt it. >> >> George, did you saw excessive fixup faults in the trace? > > No, nothing excessive; 273,480 over 30 seconds isn't that bad. The > main thing was that out of 15024 attempts to remove writable mappings, > 13775 had to fall back to a brute-force search. > > Looking at the trace, I can't really tell why there should be a > problem... I'm seeing tons of circumstances where there should only be > one writable mapping, but it falls back to brute-force search anyway. > Here's an example: > > 24.999159660 -x vmexit exit_reason EXCEPTION_NMI eip 2b105dcee330 > 24.999159660 -x wrmap-bf gfn 7453c > 24.999159660 -x fixup va 2b105f000000 gl1e 800000005caf0067 flags > (60c)-gp-Pw------ > 24.999748980 -x vmentry > [...] > 24.999759577 -x vmexit exit_reason EXCEPTION_NMI eip ffffffff8022a3b0 > 24.999759577 -x fixup:unsync va ffff88007453c008 gl1e 7453c067 flags > (c000c)-gp------ua- > 24.999762562 -x vmentry > [...] > 25.002946338 -x vmexit exit_reason CR_ACCESS eip ffffffff80491a63 > 25.002946338 -x wrmap-bf gfn 7e18c > 25.002946338 -x oos resync full gfn 7e18c > 25.002946338 -x wrmap-bf gfn 7453c > 25.002946338 -x oos resync full gfn 7453c > 25.003526640 -x vmentry > > Here we see gfn 7453c: > * promoted to be a shadow (the big 'P' in the flag string); at the > vmentry, there should be no writable mappings. > * marked out-of-sync (one writable mapping, with fixup table) > * re-sync'ed because of a CR write, and a brute-force search. > > Note that the times behind the "wrmap-bf" and "oos resync full" are > not valid; but the whole vmexit->vmentry arc takes over 1.5 > milliseconds. > > -George > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |