Re: [PATCH] Re: x86_32 tsc/pit and hrtimers

From: Chris Snook
Date: Thu Oct 09 2008 - 18:51:52 EST


Alok Kataria wrote:
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@xxxxxxxxxxxxx> 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 ?

Hardware doesn't deliberately do any TSC synchronization, though you might get it by accident in some configurations. A VMware guest gets it for free thanks to the hypervisor doing it in software, but we need to run the check when we're booting on bare metal. Jeff's patch enables the feature with as little risk as possible. TSC sync is pretty cheap, so it's not worth it to add a more dangerous special case just for guests of certain hypervisors.

-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/