The patch below should resolve this - could you please test and Ack it?

But this CPUID was present in v2.6.23 too, so why did it only show up in

2.6.24-rc for you?
	Ingo
-------------->

Subject: x86: fix get_cycles_sync() overhead

From: Ingo Molnar <mingo@elte.hu>
get_cycles_sync() is causing massive overhead in KVM networking:
   http://lkml.org/lkml/2007/12/11/54
remove the explicit CPUID serialization - it causes VM exits and is

pointless: we care about GTOD coherency but that goes to user-space

via a syscall, and syscalls are serialization points anyway.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---

 include/asm-x86/tsc.h |   12 ++++++------

 1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-x86.q/include/asm-x86/tsc.h

===================================================================

--- linux-x86.q.orig/include/asm-x86/tsc.h

+++ linux-x86.q/include/asm-x86/tsc.h

@@ -39,8 +39,8 @@ static __always_inline cycles_t get_cycl

 	unsigned eax, edx;
 	/*

-  	 * Use RDTSCP if possible; it is guaranteed to be synchronous

- 	 * and doesn't cause a VMEXIT on Hypervisors

+	 * Use RDTSCP if possible; it is guaranteed to be synchronous

+	 * and doesn't cause a VMEXIT on Hypervisors

 	 */

 	alternative_io(ASM_NOP3, ".byte 0x0f,0x01,0xf9", X86_FEATURE_RDTSCP,

 		       ASM_OUTPUT2("=a" (eax), "=d" (edx)),

@@ -50,11 +50,11 @@ static __always_inline cycles_t get_cycl

 		return ret;
 	/*

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

           |           AMD Saxony Limited Liability Company & Co. KG

 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany

 System    |                  Register Court Dresden: HRA 4896

 Research  |              General Partner authorized to represent:

 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)

           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
--

On Tue, 11 Dec 2007 15:27:17 +0100
isn't this probably wrong since this code is also used in the vsyscall code..

--

the TSC clocksource (and hence the vsyscall code) is turned off on

systems that fail the TOD/CLOCK portion of this test:
  http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
i.e. on the majority of systems in place.
	Ingo

--

Which is not on core2 which was the question about. And if it was

turned off it wouldn't use get_cycles_sync() at all.
-Andi

--

it is turned off on core2 too:
 # cat /sys/devices/system/clocksource/clocksource0/current_clocksource

 acpi_pm
	Ingo

--

but you are right that it's not turned off on all core2's, so my patch

is wrong for them.
	Ingo

--

It works, actually I already commented it out.
Acked-by: Dor Laor <dor.laor@qumranet.com>
I tried to figure out but all the code movements for i386 go in the way.

In the previous email I reported to Andi that Fedora kernel 2.6.23-8 did

not suffer from it.

Thanks for the ultra fast reply :)
--