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 14:23:53 +0100 Message-ID: <201101121423.53607.wei.wang2@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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: xen-devel@lists.xensource.com Cc: Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org Keir, Sure, that is a good question :) .=20 Actually finding a benchmark that scales with asid well is not quite easy.= =20 Benckmark like Kernbench which has large working set will occupy all tls=20 entries by its own asid. In this case, even disabling asid is not harmful. We only tested single guest with multiple vcpus. Maybe using multiple guest= s=20 or other benchmarks will show a better result? Thanks, Wei On Wednesday 12 January 2011 13:48:49 Keir Fraser wrote: > It begs the question whether it's worth complicating code for an > optimisation with no measurable benefit, doesn't it? > > -- Keir > > On 12/01/2011 12:41, "Wei Wang2" wrote: > > Hi Tim, > > Flush by ASID provides more flexible control of tlb flushing. The most > > advantage is to allow hypervisor to flush tagged tlb selectively. Using > > this feature, HV is able to flush tlb entries associated with a guest VM > > directly instead of allocating a new asid . The whole tlb flush will al= so > > be reduced by reducing asid allocation. > > > > So far, we did not measure drastic performance improvement in testing > > with kernbench and X11perf. Actually, we found out that, reducing tlb > > flushes accompanying with vmrun does not improve performance very much. > > we sent out a patch to optimize hvm_flush_guest_tlbs last week, which > > reduces over 90% tlb flushes for vmrun, and we even cannot see > > signification speedup with it. Maybe, the latency of vmrun is too big so > > that the overhead of tlb 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 > >>> VM. So hypervisor doesn't have to reassign a new ASID in order to flu= sh > >>> 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 flushi= ng > >> instead of relying on LRO) but I'm not convinced that it will be visib= le > >> 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 > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel