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

john stultz
2004-09-03T21:09:54Z

On Fri, 2004-09-03 at 13:26, Dominik Brodowski wrote:
> 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?

Well, for now I just want to re-implement what we already provide. If I
can fix something simple while I'm doing I will, but I don't want to
change behavior too much in order to simplify testing (if vanilla works
fine, and my patch breaks then I want it to be a core bug rather then a
"I changed the semantics of something slightly" issue).

Once I'm having to manage less code, I'll be very much interested in
fixing those outstanding issues. One thing at a time, and all.

> > > - 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.

Overhead? Not sure I see where that'd be a problem. The available
timesource management code needs to be split off into a timesource.c,
but I'll get to that later.

thanks
-john