Re: Performance overhead of get_cycles_sync

[Dor Laor <dor.laor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]


>> -	 * 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


[-- Attachment #1.2: Type: text/html, Size: 1453 bytes --]

[-- Attachment #2: Type: text/plain, Size: 277 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel