-* 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 sysc
On Tue, Dec 11, 2007 at 03:27:17PM +0100, Ingo Molnar wrote:
>
> * Dor Laor <[EMAIL PROTECTED]> wrote:
>
> > Here [include/asm-x86/tsc.h]:
> >
> > /* Like get_cycles, but make sure the CPU is synchronized. */
> > static __always_inline cycles_t get_cycles_sync(void)
> > {
> >unsigned long lon
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > 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.
>
> it is turned off on core2 too:
>
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> acpi_pm
but
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > * Dor Laor <[EMAIL PROTECTED]> wrote:
> >
> > 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?
>
> isn't this probably w
On Tue, 11 Dec 2007 15:27:17 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Dor Laor <[EMAIL PROTECTED]> wrote:
>
>
> 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?
isn'
Ingo Molnar wrote:
> * Dor Laor <[EMAIL PROTECTED]> wrote:
>
>
>> Here [include/asm-x86/tsc.h]:
>>
>> /* Like get_cycles, but make sure the CPU is synchronized. */
>> static __always_inline cycles_t get_cycles_sync(void)
>> {
>>unsigned long long ret;
>>unsigned eax, edx;
>>
>>/*
>>
* Dor Laor <[EMAIL PROTECTED]> wrote:
> Here [include/asm-x86/tsc.h]:
>
> /* Like get_cycles, but make sure the CPU is synchronized. */
> static __always_inline cycles_t get_cycles_sync(void)
> {
>unsigned long long ret;
>unsigned eax, edx;
>
>/*
> * Use RDTSCP if possible; it i
Ingo Molnar wrote:
>
> * Dor Laor <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo, Thomas,
> >
> > In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> > decrease for KVM networking. The reason is many vmexit (exit reason is
> > cpuid instruction) caused by calls to gettimeofday that uses t
Ingo Molnar wrote:
* Dor Laor <[EMAIL PROTECTED]> wrote:
> Hi Ingo, Thomas,
>
> In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> decrease for KVM networking. The reason is many vmexit (exit reason is
> cpuid instruction) caused by calls to gettimeofday that uses tsc
> sourcec
* Dor Laor <[EMAIL PROTECTED]> wrote:
> Hi Ingo, Thomas,
>
> In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> decrease for KVM networking. The reason is many vmexit (exit reason is
> cpuid instruction) caused by calls to gettimeofday that uses tsc
> sourceclock. read_tsc cal
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking.
The reason is many vmexit (exit reason is cpuid instruction) caused by
calls to gettimeofday that uses tsc sourceclock.
read_tsc calls get_cycles_sync which might call cpuid in order t
11 matches
Mail list logo
