From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Huang Subject: Re: [RFC PATCH 0/2] ASID: Flush by ASID Date: Wed, 12 Jan 2011 11:22:22 -0600 Message-ID: <4D2DE34E.4070702@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Wang2, Wei" , "xen-devel@lists.xensource.com" , Tim Deegan List-Id: xen-devel@lists.xenproject.org This feature isn't something ground-breaking. So we don't expect=20 significant performance improvement for many benchmarks. But it ought to=20 have a niche market for certain workloads. We will collect more=20 performance results for the next submission. The bottom line is not to=20 slowdown existing ASID implementation. Thanks, -WeiH On 01/12/2011 07:38 AM, Keir Fraser wrote: > Our gut feeling has always been that the major benefit is having two AS= IDS, > allowing one for host and one for current guest and thus avoiding TLB f= lush > on every VM entry/exit. Unless your TLB is very large, or guest vcpus r= un > only for very short periods, it's likely that a heavy guest workload > displaces all other ASIDs (guest VCPUs) from the TLB anyway. > > We're interested in benchmark numbers that can disprove the gut feeling= , of > course! > > -- Keir > > On 12/01/2011 13:23, "Wei Wang2" wrote: > >> Keir, >> Sure, that is a good question :) . >> Actually finding a benchmark that scales with asid well is not quite e= asy. >> Benckmark like Kernbench which has large working set will occupy all t= ls >> entries by its own asid. In this case, even disabling asid is not harm= ful. >> We only tested single guest with multiple vcpus. Maybe using multiple = guests >> 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 mo= st >>>> advantage is to allow hypervisor to flush tagged tlb selectively. Us= ing >>>> this feature, HV is able to flush tlb entries associated with a gues= t VM >>>> directly instead of allocating a new asid . The whole tlb flush will= also >>>> be reduced by reducing asid allocation. >>>> >>>> So far, we did not measure drastic performance improvement in testin= g >>>> with kernbench and X11perf. Actually, we found out that, reducing tl= b >>>> flushes accompanying with vmrun does not improve performance very mu= ch. >>>> we sent out a patch to optimize hvm_flush_guest_tlbs last week, whic= h >>>> reduces over 90% tlb flushes for vmrun, and we even cannot see >>>> signification speedup with it. Maybe, the latency of vmrun is too bi= g 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 id= ea is >>>>>> to allow CPU to flush TLBs associated with the ASID assigned to gu= est >>>>>> VM. 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 flu= shing >>>>> instead of relying on LRO) but I'm not convinced that it will be vi= sible >>>>> 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 >> >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >