From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: Performance overhead of get_cycles_sync Date: Wed, 12 Dec 2007 02:19:16 +0200 Message-ID: <475F2904.2050209@qumranet.com> References: <475E8C8B.7070308@qumranet.com> <20071211133738.GA8150@elte.hu> <475E9A92.4030001@qumranet.com> <20071211142717.GA15903@elte.hu> <20071211212628.GB6537@amd.com> Reply-To: dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1803926498==" Cc: kvm-devel , Andi Kleen , Linux Kernel Mailing List To: Joerg Roedel Return-path: In-Reply-To: <20071211212628.GB6537-5C7GfCeVMHo@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --===============1803926498== Content-Type: multipart/alternative; boundary="------------010607040000050906060003" This is a multi-part message in MIME format. --------------010607040000050906060003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> - * Don't do an additional sync on CPUs where we know >> - * RDTSC is already synchronous: >> + * Use RDTSC on other CPUs. This might not be fully synchronous, >> + * but it's not a problem: the only coherency we care about is >> + * the GTOD output to user-space, and syscalls are synchronization >> + * points anyway: >> */ >> - alternative_io("cpuid", ASM_NOP2, X86_FEATURE_SYNC_RDTSC, >> - "=a" (eax), "0" (1) : "ebx","ecx","edx","memory"); >> rdtscll(ret); >> >> return ret; >> > > I don't think this is a good idea. I discussed exactly this item with > Andi Kleen a while ago and afair the serializing instruction was > necessary to fix a backwards walking gettimeofday() on some K8 > revisions. Andi Kleen can tell more details, I added him to the CC list. > > Joerg > > So I suggest we'll wait for Andi Kleen's 24' patch using [l|m]fence. Meanwhile one shouldn't use tsc clock source in guests or alternatively mascaraed the guest cpu as old Intel version [one can do that with kvm, although it hurt performance]. Regards, Dor --------------010607040000050906060003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
-	 * Don't do an additional sync on CPUs where we know
-	 * RDTSC is already synchronous:
+	 * Use RDTSC on other CPUs. This might not be fully synchronous,
+	 * but it's not a problem: the only coherency we care about is
+	 * the GTOD output to user-space, and syscalls are synchronization
+	 * points anyway:
 	 */
-	alternative_io("cpuid", ASM_NOP2, X86_FEATURE_SYNC_RDTSC,
-			  "=a" (eax), "0" (1) : "ebx","ecx","edx","memory");
 	rdtscll(ret);
 
 	return ret;
    

I don't think this is a good idea. I discussed exactly this item with
Andi Kleen a while ago and afair the serializing instruction was
necessary to fix a backwards walking gettimeofday() on some K8
revisions. Andi Kleen can tell more details, I added him to the CC list.

Joerg
So I suggest we'll wait for Andi Kleen's 24' patch using [l|m]fence.
Meanwhile one shouldn't use tsc clock source in guests or alternatively mascaraed the guest cpu as
old Intel version [one can do that with kvm, although it hurt performance].
Regards,
Dor

--------------010607040000050906060003-- --===============1803926498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php --===============1803926498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============1803926498==--