* Daniel Walker ([EMAIL PROTECTED]) wrote:
> 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.
>
The other solution, good for UP, would be to sychronize the TSC with
another clock source (HPET or timer), but it starts to look pretty much
like what is done right now.
> > > > /* 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 ?
>
For kernel and user space tracing, those small jumps are very annoying :
it can show, in a trace, that a fork() appears on a CPU after the first
schedule() of the thread on the other CPU : scheduling causality relationship
can become very hard to follow. This is only a sample case. Inaccuracy and
periodical modification of the clock time (non monotonic) can cause important
inaccuracy in performance tests, even on UP systems. A monotonic clock,
accessible from anywhere in kernel space (including NMI handler) and
from user space is very useful for performance analysis and, more
generally, for timestamping data in per cpu buffers so it can be later
reordered correctly.
Mathieu
> Daniel
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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/
