Re: [RFC] New Time of day proposal (updated 9/2/04)

Dominik Brodowski
2004-09-03T20:53:57Z

On Fri, Sep 03, 2004 at 12:41:22PM -0700, john stultz wrote:
> > - cpufreq hooks to tsc.c and i386_tsc.c[*] can easily be added. For them to
> > work _better_ than current code: can timeofday_hook() be called (with IRQs
> > disabled) _anywhen_ from kernel context?
> > [*] actually, only one of them needs the notifier, AFAICS...
>
> Yep, that's on my list. I'm trying to keep to just cleaning up one thing
> at a time, but since I've got to re-work the timer_tsc.c code anyway, I
> figured I'd try to organize all the TSC related functions
> (synchronization, cpufreq, get_cycles(), tsc_delay maybe?) into tsc.c.
> This will simplify things if we ever get around to correctly fixing the
> SMP systems w/ different speed cpus issue.

What about removing cpu_freq_khz you have in your patch, adding a per-CPU
value, and just use the value of the boot CPU for the other CPUs if
!CONFIG_DIFFERENT_CPU_SPEEDS or something like that?

> > - what about keeping lower-priority timesources still "active" in some sort to
> > a) enable loading _and_ unloading timsources (even modularizing them
> > becoms possible which should make testing easier...),
> > b) call them every couple of seconds to verify the currently used
> > timesource is still sane (and if not, call cpufreq_delayed_get() for
> > example or disable the timesource). This would mean that e.g. pmtmr
> > and pit can be used to "verify" and "backup" tsc, or otherwise...
> > The "clock=tsc" override would only affect the priority of the
> > timesource then, making it so large that no other timesource can
> > "preempt" it, but doesn't avoid making other timesources available
> > for backup and verification purposes.
>
> That's totally the plan, although I want to put the control into sysfs.

Even better. Thought about that too, but was worried you'd dislike the sysfs
overhead.

Thanks,
Dominik