Re: rfc: high-resolution timer framework

[christos%astron.com@localhost (Christos Zoulas)]

In article <20080801145240.GO22423%shisha.spb.ru@localhost>,
Alexander Shishkin  <alexander.shishkin%teleca.com@localhost> wrote:
>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.

Well, it will definitely get more testing if it replaces 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/

Looks good. I'd make cnt volatile to prevent gcc optimizing away your loop.

christos