Re: [RFC] New timeofday proposal (v.A1)

[Christoph Lameter]

On Tue, 7 Dec 2004, john stultz wrote:

> Features of this design:
> ========================

> o Consolidates a large amount of code:
> 	Allows for shared times source implementations, such as: i386, x86-64
> and ia64 all use HPET, i386 and x86-64 both have ACPI PM timers, and
> i386 and ia64 both have cyclone counters. Time sources are just drivers!

What I would to see also included here is to provide a clean posix
interface to these drivers. IMHO the current char interfaces to clock
drivers should be removed. Look at SGI's mmtimer implementation in
2.6.10-rc3. We have modified the posix interface to allow clock drivers to
export their timer values via CLOCK_SGI_CYCLE and we are also
now able to schedule hardware interrupts via timer_* posix functions
utilizing CLOCK_SGI_CYCLE that are then delivered as signals to an
application. Timer chips usually include time sources as well as the
ability to generate periodic or single shot
interrupts. There needs to be some way for clock drivers to cleanly
interface with these. The API may be the posix subsystem but I do not
like the quality of the code nor the current API for the clock drivers.

The API for user space to clocks already exists through the posix
standard. I would suggest to work with that standard for a way to deal
with clocks under Linux.

> Brief Psudo-code to illustrate the design:
> ==========================================
>
> monotonic_clock()
> 	now = timesource_read();	/* read the timesource */
> 	ns = cyc2ns(now - offset_base);	/* calculate nsecs since last hook */
> 	ntp_ns = ntp_scale(ns);		/* apply ntp scaling */

These are not really functions right? timesource_read can be a direct
memory read and the cyc2ns and ntp_scale can be reduced to some scaling
factor?

> Points I'm glossing over for now:
> ====================================================
>
> o ntp_scale(ns):  scales ns by NTP scaling factor
> 	- see ntp.c for details
> 	- costly, but correct.

Please do not call this function from monotonic_clock but provide some
sort of scaling factor that is adjusted from time to time.

> o What is the cost of throwing around 64bit values for everything?
> 	- Do we need an arch specific time structure that varies size
> accordingly?

I think 64 bit values are fine but then I work for a 64 bit company and
this may just be the contextual predisposition.

> o Some arches (arm, for example) do not have high res timing hardware
> 	- In this case we can have a "jiffies" timesource
> 		- cyc2ns(x) =  x*(NSEC_PER_SEC/HZ)
> 		- doesn't work for tickless systems

In that case maybe the "ticks" are the timesource and not really tick
processing per se.
There could be a separation between "increment counter" and tick processing.
-
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/