From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang2 Subject: Re: [RFC PATCH 0/2] ASID: Flush by ASID Date: Wed, 12 Jan 2011 13:41:10 +0100 Message-ID: <201101121341.11200.wei.wang2@amd.com> References: <201101111855.52793.wei.wang2@amd.com> <20110112101700.GG5651@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20110112101700.GG5651@whitby.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Hi Tim, =46lush by ASID provides more flexible control of tlb flushing. The most=20 advantage is to allow hypervisor to flush tagged tlb selectively. Using thi= s=20 feature, HV is able to flush tlb entries associated with a guest VM directl= y=20 instead of allocating a new asid . The whole tlb flush will also be reduced= =20 by reducing asid allocation. =20 So far, we did not measure drastic performance improvement in testing with= =20 kernbench and X11perf. Actually, we found out that, reducing tlb flushes=20 accompanying with vmrun does not improve performance very much.=20 we sent out a patch to optimize hvm_flush_guest_tlbs last week, which reduc= es=20 over 90% tlb flushes for vmrun, and we even cannot see signification speedu= p=20 with it. Maybe, the latency of vmrun is too big so that the overhead of tlb= =20 flush is negligible? Thanks, Wei On Wednesday 12 January 2011 11:17:00 Tim Deegan wrote: > At 17:55 +0000 on 11 Jan (1294768552), Wei Wang2 wrote: > > Future AMD SVM supports a new feature called flush by ASID. The idea is > > to allow CPU to flush TLBs associated with the ASID assigned to guest V= M. > > So hypervisor doesn't have to reassign a new ASID in order to flush > > guest's VCPU. Please review it. > > What advantage does the new system have? Intuitively it seems like it > might be a tiny bit fairer and a tiny bit faster (by explicitly flushing > instead of relying on LRO) but I'm not convinced that it will be visible > in macro-benchmarks. Have you measured it? > > Cheers, > > Tim. > > > Thanks, > > Wei > > > > Signed-off-by: Wei Huang > > Signed-off-by: Wei Wang > > -- > > Advanced Micro Devices GmbH > > Sitz: Dornach, Gemeinde Aschheim, > > Landkreis M=FCnchen Registergericht M=FCnchen, > > HRB Nr. 43632 > > WEEE-Reg-Nr: DE 12919551 > > Gesch=E4ftsf=FChrer: > > Alberto Bozzo, Andrew Bowd > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel