[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rfc: high-resolution timer framework
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  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
>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
Looks good. I'd make cnt volatile to prevent gcc optimizing away your loop.
Main Index |
Thread Index |