Re: [PATCH] tsc-disable_B9

[george anzinger]

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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   [e-mail]
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml