Re: Linux time code

[john stultz]

On Thu, 2006-08-17 at 09:20 +0200, Ulrich Windl wrote:
> On 16 Aug 2006 at 12:53, john stultz wrote:
> > As you know, myself and others are working on this. Its taken quite a
> > bit of time to get some of the groundwork in, and cleanups are still
> > needed, but I think we're on the right track. However, criticism is
> > welcome, and I'd appreciate your input (I did try to keep you CC'ed on
> > most of the early discussions, but forgive me as I left you out on some
> > of the more recent discussions)
> 
> No problem, I was on holiday anyway. The code I tried had a problem with my ADM 
> Athlon X2 (Dual core): Both cores run with different frequency, a feature of power 
> management, thus making hi-res timing instable. I haven't investigated in-depth, 
> but I thought the hpet timer was used.

Hmmm.. The dualcore AMD TSC usage issue should be resolved now, so
please let me know if you can provide any further info on what you saw
(dmesg, config).


> > > For example there is a POSIX-like sys_clock_gettime() intended to 
> > > server the end-user directly, but there's no counterpart do_clock_gettime() to 
> > > server any in-kernel needs. 
> > 
> > Hmmm.. ktime_get(), ktime_get_ts() and ktime_get_real(), provide this
> > info. Is there something missing here?
> 
> From memory: Are those exported from posix_timer? I think I saw those, but wasn't 
> sure whether they are for general cross-arch use.

They should be cross-arch safe. Exported from ktime.h
 
> > The NTP PPS code was dropped because there were no in-kernel users of
> > that interface. But as I've always said, I'd be very happy to see your
> > PPS work get merged. I know there are a few out-of-tree patches
> > currently floating around (Udo mailed me awhile back with some links,
> > but I can't find them at the moment), and I'm sure due to the high level
> > of activity in this area makes it difficult to keep out of tree patches
> > up to date. Is there any reason these patches aren't being pushed into
> > mainline?
> 
> I'm only waiting for a "pusher" ;-) No actually I have my own quality check, and 
> currently the code fails those. It's named "alpha" by myself. Unless it's "beta" I 
> won't ask anybody for inclusion.

Even so, if I recall, your earlier PPS kit patch had both cleanups and
new features. Breaking that up and pushing just the cleanups might be an
easy way to reduce the patch size you have to maintain until its beta.

> I don't like the idea of a loadable module, because most of the code accesses 
> several timing variables that are (or can be) private now. A module would make 
> them public (for misuse). The time machinery should be a sealed black box IMHO.

Agreed, although interfaces can be added if necessary, so let me know if
you find anything specific that is lacking.


thanks
-john

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