Re: xen-unstable, winxp32 very poor performance on AMD FX-8150, I bisected and changeset is 24770:7f79475d3de7

[Peter Maloney <peter.maloney@brockmann-consult.de>]

[-- Attachment #1.1: Type: text/plain, Size: 4485 bytes --]

On 01/18/2013 03:30 PM, George Dunlap wrote:
> On Sat, Jan 12, 2013 at 3:25 PM, Peter Maloney
> <peter.maloney@brockmann-consult.de
> <mailto:peter.maloney@brockmann-consult.de>> wrote:
>
>     On 11/22/2012 07:54 PM, Peter Maloney wrote:
>     > On 11/13/2012 02:17 PM, Peter Maloney wrote:
>     >> On 2012-11-01 18:28, Andres Lagar-Cavilla wrote:
>     >>> On Nov 1, 2012, at 1:00 PM, Tim Deegan <tim@xen.org
>     <mailto:tim@xen.org>> wrote:
>     >>>
>     >>>> Hi,
>     >>>>
>     >>>> At 14:59 +0100 on 22 Oct (1350917960), Tim Deegan wrote:
>     >>>>> At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
>     >>>>>> The change was 8 months ago
>     >>>>>>
>     >>>>>> changeset:   24770:7f79475d3de7
>     >>>>>> user:        Andres Lagar-Cavilla <andres@lagarcavilla.org
>     <mailto:andres@lagarcavilla.org>>
>     >>>>>> date:        Fri Feb 10 16:07:07 2012 +0000
>     >>>>>> summary:     x86/mm: Make p2m lookups fully synchronized
>     wrt modifications
>     >>>> [...]
>     >>> Not any immediate ideas without profiling.
>     >>>
>     >>> However, most callers of hvmemul_do_io pass a stub zero
>     ram_gpa address. We might be madly hitting the p2m locks for no
>     reason there.
>     >>>
>     >>> How about the following patch, Peter, Tim?
>     > I tried the patch applied to xen-unstable 4.2.0-branched
>     > 528f0708b6db+ 4.2.0-branched
>     >
>     > It seemed the same. It was extremely slow with 7 vcpus, and with
>     2 vcpus
>     > it was slow, but fast enough that I could bother to log in and out
>     > during the test.
>     >
>     > Attached are logs generated with this command (using xm instead
>     of xl):
>     > for i in {1..30}; do xm debug-keys d; xm dmesg -c; done >> nameoflog
>     >
>     > xenxp_xm_dmesg_-c_7cpus_idle.log
>     > xenxp_xm_dmesg_-c_7cpus_logintooslow.log
>     > xenxp_xm_dmesg_-c_7cpus_shutdown.log
>     > xenxp_xm_dmesg_-c_duringlogin.log
>     > xenxp_xm_dmesg_-c_idling_login_screen.log
>     >
>     > Also there is xenxp_dmesg.log which is output from hitting
>     alt+sysrq+w
>     > and p in case it's relevant.
>     >
>     > BTW this time I am testing with kernel 3.6.7
>     >
>
>     I also tested 4.2.1 now, and it has the same problem. And after
>     using it
>     for a while with windows 8 (playing games), I get the general feel
>     that
>     it is laggier than with 4.1.3. And now I'm using 4.1.4 which is fast
>     like 4.1.3.
>
>     So any ideas on how to fix this or gather more useful information?
>
>
> Pete,
>
> One thing that would be helpful is if we could have a quantifiable
> difference, other than "feels laggier".  If this is related to the
> problem I saw a few months ago, running winXP and looking at "top" in
> qemu is pretty clear.  If you have a bit of time, do you suppose you
> could try to look around for a freely-available benchmark that would
> give us some numbers for Windows 8?  That might help us track down the
> problem better as well.
>
> I've put this on my 4.3 release tracking list, so it should get attention.
>
>  -George
Unfortunately, "Feels laggier" is hard to put into numbers. I don't mean
the fps, iops is lower, or the cpu % is higher, etc. I mean that at
random times something I did doesn't respond as quickly as normal. Or in
other words not 10% slower 100% of the time (which benchmarks seem to
say, and doesn't bother me so much, but should bother businesses), but
more like 800% slower 1% of the time (which is bad for games, so bothers
me much but might not matter as much to businesses).

Attached is a tgz of benchmark results from PCMark7 on win8 preview, and
PCMark5 on winxp, comparing xen 4.1.4 and 4.2.1.

(and when shutting down win8 in 4.2.1, skype in dom0 stopped working,
and no more domus would start, so I had to reboot to do the xp test, but
I believe this is a separate issue.)


When testing XP and 4.2.1, here is what xm top showed for cpu% (2 vcpus):
Idle: around 80-95%
During single tests: around 130%
During the last test which does 4 or 5 tests together: 198.2%

When testing 8 and 4.2.1,
Idle: dom0 44%, domu 24%
During tests around 200% (seems normal)

When testing XP and 4.1.4 ... mdadm decided to resync a disk at this
time (it does this occasionally when I reboot many times, esp. when
things go wrong like the 'no more domus would start' issue), so this may
be terribly invalid:
Idle: dom0 44%, domu bouncing between 30-70%


Is this the sort of thing you expected from me?

Peter


[-- Attachment #1.2: Type: text/html, Size: 7475 bytes --]

[-- Attachment #2: xenbenchmarks.tgz --]
[-- Type: application/x-compressed-tar, Size: 3392978 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel