Messages in this thread |  | | | Date | Fri, 09 Aug 2002 11:49:55 -0700 | | From | george anzinger <> | | Subject | Re: [PATCH] tsc-disable_B9 |
| |
john stultz wrote: > > On Fri, 2002-08-09 at 02:17, Alan Cox wrote: > > On Fri, 2002-08-09 at 03:30, john stultz wrote: > > > Not sure I followed that, do you mean per-cpu TSC management for > > > gettimeofday? > > > > We have some x86 setups where people plug say a 300MHhz and a 450MHz > > celeron into the same board. This works because they are same FSB, > > different multiplier (works and intel certify being two different > > things) > > Oh yes, with the old NUMAQ hardware here, one can mix nodes of different > speed cpus. Once I get a chance, I'm going to begin working on this > issue for 2.5. My plan right now is to keep per-cpu last_tsc_low and > fast_gettimeoffset_quotient values, then round robin the timer > interrupt. > An interesting approach, however, could you take a look at the high-res-timers patch (see signature). In that code (in the TSC version), we use the TSC to update jiffies and _sub_jiffie (which is TSC counts into the next jiffie). We also want to be able to "grab" a new TSC and figure the time quickly, without updating either jiffies or _sub_jiffie. Your approach would, I think, mean that both jiffies and _sub_jiffie would be per cpu values, not impossible, but, well, hard.
On the other hand, the high-res-timers patch also allows one to use the ACPI pm timer, and ignore TSC completely :)
-g > > > Needless to say tsc does not work well on such boxes. Thats why I don't > > trust the tsc at all in such cases. Since you'll have the nice cyclone > > timer for the Summit it seems best not to trust it, and on the summit to > > use the cyclone for udelay as well ? > > > > I agree dodgy_tsc needs to change name. Perhaps we actually want > > > > int tsc = select_tsc(); > > > > switch(tsc) > > { > > case TSC_CYCLONE: > > case TSC_PROCESSOR: > > case TSC_NONE: > > .. > > } > > Sounds good. I'll re-work my patch and resubmit. > > thanks! > -john > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |