Messages in this thread | | | Subject | Re: [PATCH] Re: x86_32 tsc/pit and hrtimers | From | Alok Kataria <> | Date | Thu, 09 Oct 2008 14:53:40 -0700 |
| |
On Thu, 2008-10-09 at 14:03 -0700, Chris Snook wrote: > Alok kataria wrote: > > On Thu, Oct 9, 2008 at 12:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > >> On Thu, 9 Oct 2008, Jeff Hansen wrote: > >> > >>> OK, so are we all agreed that something like clocksource_trust=tsc would be > >>> the best? > >> No, it's per affected device: tsc=trust or tsc=stable or whatever > >> unintuitive name we want to come up. And it is a modification to TSC > >> not to the clocksource layer. > > > > Yep, this is cool. I too have a patch in my local tree which does a > > similar thing i have a tsc_reliable flag which is set right now only > > when we are running under a VMware hypervisor. > > Along with marking the no_verify flag for TSC, this patch of mine also > > skips the TSC synchornization checks. > > > > The TSC synchronization loop which is run whenever a new cpu is > > brought up is not actually needed on systems which are known to have a > > reliable TSC. TSC between 2 cpus can be off by a marginal value on such > > systems and thats okay for timekeeping, since we do check for tsc going > > back in read_tsc. > > > > Can this reasoning be included and synchronization skipped for all > > these systems with reliable aka trustworthy TSC's ? > > In general, no. Not all hardware/hypervisors behave this way, even when the TSC > is otherwise stable once synchronized.
I agree that in general this should be no, but since this is a commandline variable it will be normally set for only those systems which have only TSC as a option or know that the TSC is reliable. wouldn't doing this be ok for such systems ?
Thanks, Alok
> > -- Chris
| |