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
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > the TSC clocksource (and hence the vsyscall code) is turned off on
> > systems that fail the TOD/CLOCK portion of this test:
>
> Which is not on core2 which was the question about. And if it was
> turned o
Ingo Molnar <[EMAIL PROTECTED]> writes:
> the TSC clocksource (and hence the vsyscall code) is turned off on
> systems that fail the TOD/CLOCK portion of this test:
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
--
To
* 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;
/*
* Use RDTSCP if possible
On Tue, Dec 11, 2007 at 04:57:16PM +0200, Dor Laor wrote:
> Andi Kleen wrote:
> >[headers rewritten because of gmane crosspost breakage]
> >
> >
> >>In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> >>decrease for KVM networking.
> >>
> >
> >That should not have changed for
Andi Kleen wrote:
[headers rewritten because of gmane crosspost breakage]
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking.
That should not have changed for quite some time.
Also it depends on the CPU of course.
I didn't find the exact
* 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
[headers rewritten because of gmane crosspost breakage]
> In the latest kernel (2.6.24-rc3) I noticed a drastic performance
> decrease for KVM networking.
That should not have changed for quite some time.
Also it depends on the CPU of course.
> The reason is many vmexit (exit reason is cpuid
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
14 matches
Mail list logo
