On Mon, 2007-02-26 at 15:53 -0500, Mathieu Desnoyers wrote:
> > > /* On frequency change event */
> > > /* In irq context */
> > > void freq_change_cb(unsigned int new_freq)
> > > {
> >
> > It's possible for the TSC to change frequencies without notification. It
> > can also completely stop when the system goes idle.
> >
>
> Hrm, I see. I though those freq change without notification would happen
> rarely and could be dealt by resynchronizing the CPUs. I guess I was
> wrong.
The system could be UP .. I don't think tracking this kind of thing is
trival, and given the TSC track record you have to assume there are will
be other issue in the future.
> > > /* Userspace */
> > > /* Export all this data to user space through the vsyscall page. Use a
> > > function
> > > * like read_time to read the walltime. This function can be implemented
> > > as-is
> > > * because it doesn't need to disable preemption. */
> >
> > What would be the benefit of using this over the vsyscall gettimeofday()
> > from userspace ?
> >
>
> So we can get a monotonic, non NTP corrected timestamp quickly from user
> space without going through a system call. Are there other alternatives ?
The NTP daemon needs to be active AFAIK before you would start observing
weird time jumps. There are adjustments made without NTP but they are
only seen over short periods.. So I still think gettimeofday() would be
an alternative ..
Have you considered adding something to glibc? You could access only the
TSC from userspace.. I don't think the addition of a vsyscall/syscall
for this would go over too well considering that there are other ways to
get timestamps. It might help if you tell us what you think this would
be used for in userspace ?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
