From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.3 development update Date: Tue, 7 May 2013 15:57:30 +0100 Message-ID: <5189165A.6010509@eu.citrix.com> References: <515B186F02000078000CA1A7@nat28.tlf.novell.com> <20130402163440.GB17022@ocelot.phlegethon.org> <515BF5F102000078000CA39C@nat28.tlf.novell.com> <515C0A0D.6020007@eu.citrix.com> <4691AE88-FA92-4826-BF5E-50175BACA5D9@gmail.com> <20130404152321.GI42936@ocelot.phlegethon.org> <20130404170507.GJ42936@ocelot.phlegethon.org> <517E73DE.7090803@brockmann-consult.de> <20130507135639.GF11427@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: <20130507135639.GF11427@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: Jan Beulich , "Tim (Xen.org)" , "xen-devel@lists.xen.org" , "suravee.suthikulpanit@amd.com" , Andres Lagar-Cavilla , Peter Maloney List-Id: xen-devel@lists.xenproject.org On 07/05/13 14:56, Pasi K=E4rkk=E4inen wrote: > On Mon, Apr 29, 2013 at 03:21:34PM +0200, Peter Maloney wrote: >> On 04/04/2013 07:05 PM, Tim Deegan wrote: >>> At 16:23 +0100 on 04 Apr (1365092601), Tim Deegan wrote: >>>> At 11:34 -0400 on 03 Apr (1364988853), Andres Lagar-Cavilla wrote: >>>>> On Apr 3, 2013, at 6:53 AM, George Dunlap wrote: >>>> Yes, 4.2 is definitely slower. A compile test on a 4-vcpu VM that tak= es >>>> about 12 minutes before this locking change takes more than 20 minutes >>>> on the current tip of xen-unstable (I gave up at 22 minutes and reboot= ed >>>> to test something else). >>> I did a bit of prodding at this, but messed up my measurements in a >>> bunch of different ways over the afternoon. :( I'm going to be away >>> from my test boxes for a couple of weeks now, so all I can say is, if >>> you're investigating this bug, beware that: >>> >>> - the revision before this change still has the RTC bugs that were >>> fixed last week, so don't measure performance based on guest >>> wallclock time, or your 'before' perf will look too good. >>> - the current unstable tip has test code to exercise the new >>> map_domain_page(), which will badly affect all the many memory >>> accesses done in HVM emulation, so make sure you use debug=3Dn buil= ds >>> for measurement. >>> >>> Also, if there is still a bad slowdown, caused by the p2m lookups, this >>> might help a little bit: >>> >>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >>> index 38e87ce..7bd8646 100644 >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -1361,6 +1361,18 @@ int hvm_hap_nested_page_fault(paddr_t gpa, >>> } >>> } >>> = >>> + >>> + /* For the benefit of 32-bit WinXP (& older Windows) on AMD CPUs, >>> + * a fast path for LAPIC accesses, skipping the p2m lookup. */ >>> + if ( !nestedhvm_vcpu_in_guestmode(v) >>> + && gfn =3D=3D vlapic_base_address(vcpu_vlapic(current)) >> PA= GE_SHIFT ) >>> + { >>> + if ( !handle_mmio() ) >>> + hvm_inject_hw_exception(TRAP_gp_fault, 0); >>> + rc =3D 1; >>> + goto out; >>> + } >>> + >>> p2m =3D p2m_get_hostp2m(v->domain); >>> mfn =3D get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, >>> P2M_ALLOC | (access_w ? P2M_UNSHARE : 0= ), NULL); >> This patch (applied to 4.2.2) has a very large improvement on my box >> (AMD FX-8150) and WinXP 32 bit. >> >> It only took about 2.5 minutes to log in and see task manager. It takes >> about 6 minutes without the patch. And 2.5 minutes is still terrible, >> but obviously better. >> > So is the problem only on WinXP with "booting up / logging in to windows", > or do you see performance regressions on some actual benchmark tools aswe= ll > (after windows has started up) ? For the sake of people watching this thread: The last 4-5 mails I've = sent to Peter Maloney have bounced with "Mailbox Full" messages; so it's = possible he's not actually hearing this part of the discussion... -George