[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1224713046.13953.40.camel@alok-dev1>
Date: Wed, 22 Oct 2008 15:04:06 -0700
From: Alok Kataria <akataria@...are.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is
set.
On Wed, 2008-10-22 at 13:17 -0700, Andi Kleen wrote:
> > the sync check is there to check the _offset_ between CPUs. CONSTANT_TSC
> > is not a guarantee that the TSC will be coherent across all CPUs.
>
> I cannot find a quote for it in the docs now, but iirc the AMD
> definition of the bit guarantees offset, aka full synchronization
> over the system.
I found this mail,
http://lkml.org/lkml/2005/11/4/173
If you look for,
-------------------------------------------------------------
Future TSC Directions and Solutions
===================================
Future AMD processors will provide a TSC that is P-state and
C-State invariant and unaffected by STPCLK-throttling. This
will make the TSC immune to drift. Because using the TSC
for fast timer APIs is a desirable feature that helps
performance, AMD has defined a CPUID feature bit that
software can test to determine if the TSC is
invariant. Issuing a CPUID instruction with an %eax register
value of 0x8000_0007, on a processor whose base family is
0xF, returns "Advanced Power Management Information" in the
%eax, %ebx, %ecx, and %edx registers. Bit 8 of the return
%edx is the "TscInvariant" feature flag which is set when
TSC is P-state, C-state, and STPCLK-throttling invariant; it
is clear otherwise.
--------------------------------------------------------------
The third line does mention about invariant TSC being immune to drift.
Thanks,
Alok
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists