Re: rfc: high-resolution timer framework

[Alexander Shishkin <alexander.shishkin%teleca.com@localhost>]

On Fri, Jul 18, 2008 at 01:50:41PM +0000, Christos Zoulas wrote:
Here [1] goes the updated version, please have a look.

> >>    be inside the union since they are only used in realtime timers?
> >They are only used for CLOCK_HIGHRES timers (which I think at some point
> >might take place of realtime timers), but yes, you're right, they belong
> >in that union.
> 
> Actually this was my other question. Why not replace the REALTIME timers
> now?
Well, I was rather hoping that this code receives a fair amount of
testing before it can take the place of CLOCK_REALTIME.

> >> c. why does hrtimerfix limit the minimum sleep time to 1000ns [1us]?
> >I think it has to be dynamically calculated, say, at boot or at least,
> >made machine-dependant constant. What do you think?
> 
> Yes, I think so. I don't know how to do it though.
Here's an attempt at implementing this through so-called calibration.
I'm not entirely sure, however, about the sort of pattern which should
be used for calibration.

> >> d. tc_hrtim_getbest() looks very similar to tc_pick. Perhaps they can
> >>    be merged. Also, can't you cache the result, so that you don't need
> >>    to look each time?
> >The original idea was to pick a best suitable (in terms of frequency or
> >quality or whatnot) hardware for each timer created, depending on, say,
> >requested interval and taking into consideration other issues, like
> >certain timers not being available due to a power saving mode or
> >something else. I've never got to implementing this quite yet, so for
> >now it probably makes sense to do it your way.
> 
> Ok. Still, this function should be implemented once...
For now, I moved merged the functions so that there's no duplicated
code.

[1]: http://koowaldah.org/people/ash/netbsd/010808/

Regards,
--
Alex