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

[Dominik Brodowski]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/