Messages in this thread Patch in this message | | | Date | Fri, 10 Oct 2008 08:24:53 -0600 (MDT) | From | Jeff Hansen <> | Subject | [PATCH] Re: x86_32 tsc/pit and hrtimers |
| |
This one is against 2.6.27.
[X86] Add tsc=stable option for marking TSC as stable
This enables legacy hardware or VMs without HPET, LAPIC, or ACPI timers to enter high-resolution timer mode.
Signed-off-by: Jeff Hansen <jhansen@cardaccess-inc.com> --- Documentation/kernel-parameters.txt | 4 ++++ arch/x86/kernel/tsc.c | 11 +++++++++++ 2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1150444..0528bcb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2174,6 +2174,10 @@ and is between 256 and 4096 characters. It is defined in the file Format: <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq>
+ tsc= [X86-32,X86-64] + tsc=stable: Mark TSC clocksource as stable, enabling + high-resolution timer mode on older hardware. + turbografx.map[2|3]= [HW,JOY] TurboGraFX parallel port interface Format: diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 8f98e9d..70e485e 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -98,6 +98,17 @@ int __init notsc_setup(char *str)
__setup("notsc", notsc_setup);
+static struct clocksource clocksource_tsc; + +static int __init tscx_setup(char *str) +{ + if (!strcmp(str, "stable")) + clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY; + return 1; +} + +__setup("tsc=", tscx_setup); + #define MAX_RETRIES 5 #define SMI_TRESHOLD 50000
-- 1.5.6.4 --------------------------------------------------- "If someone's gotta do it, it might as well be me." On Thu, 9 Oct 2008, Chris Snook wrote:
> Alok Kataria wrote: >> On Thu, 2008-10-09 at 15:50 -0700, Chris Snook wrote: >> > Alok Kataria wrote: >> > > On Thu, 2008-10-09 at 14:03 -0700, Chris Snook wrote: >> > > >> > > 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. >> >> The TSC sync algorithm right now expects that TSC are perfectly in sync >> between cpus. >> But, the hardware doesn't deliberately do any synchronization, so we can >> have situations where TSC was (accidently ? )off by a marginal value >> during boot and as a result we mark TSC as unstable and don't use it as >> a clocksource at all. For systems like the ones Jeff is using wouldn't >> that be a problem. IOW, even though the TSC was *marginally* off during >> bootup it should still be used as a clocksource, since you have no other >> option, no ? > > You seem to be conflating position and rate. When we mark TSC as stable, > we're saying it will always advance at a known rate on all CPUs, but this > says nothing about the relative positions on the different CPUs. That skew > can be huge on some hardware, not just marginal, so we still need to > synchronize them at boot time, even though we don't need to (and can't, in > this case) verify stability with another continuous clock source. > > -- Chris > >
| |