From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: xen-unstable, winxp32 very poor performance on AMD FX-8150, I bisected and changeset is 24770:7f79475d3de7 Date: Fri, 18 Jan 2013 14:22:31 +0000 Message-ID: <50F95AA7.4050301@eu.citrix.com> References: <5082DD8C.2030608@brockmann-consult.de> <20121022135920.GE12577@ocelot.phlegethon.org> <20121101170016.GD61948@ocelot.phlegethon.org> <50A2484D.309@brockmann-consult.de> <50AE74DA.6080808@brockmann-consult.de> <50F1807B.2060808@brockmann-consult.de> <20130117205737.GZ8912@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20130117205737.GZ8912@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Andres Lagar-Cavilla , "Tim (Xen.org)" , Peter Maloney , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 17/01/13 20:57, Pasi K=E4rkk=E4inen wrote: > Hello, > > George: What do you think, should we add this bug to the Xen 4.3 status e= mail for tracking it? > It's a serious HVM/winxp performance regression on AMD.. Hey Pasi -- thanks for bringing this thread to my attention. I had = noticed a performance impact on AMD boxen myself, but investigating it = had kind of gotten buried in more urgent tasks. Yes, I think we should = track it. I'll put it on the list. -George > > -- Pasi > > On Sat, Jan 12, 2013 at 04:25:47PM +0100, Peter Maloney 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 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 >>>>>>>> date: Fri Feb 10 16:07:07 2012 +0000 >>>>>>>> summary: x86/mm: Make p2m lookups fully synchronized wrt modif= ications >>>>>> [...] >>>>> Not any immediate ideas without profiling. >>>>> >>>>> However, most callers of hvmemul_do_io pass a stub zero ram_gpa addre= ss. 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? >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel