Re: rfc: high-resolution timer framework

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

On Wed, Jul 16, 2008 at 03:42:20PM +0000, Christos Zoulas wrote:
> a. Shouldn't the members
> 
>       pt_rb_node,
>       pt_on_rb,
>       pt_cpuidx,
>       pt_hrtim,
> 
>    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.

> b. Is pt_on_rb necessary? perhaps a -1 cpuid can indicate this?
Indeed it can.

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

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

> e. Perhaps you want to re-order the members of lapic timer so that the
>    64 bit members are quadword aligned?
Yes, you're right.

Thanks a lot for taking time and providing comments. I'll be back with
an updated version in a while.

Regards,
--
Alex