tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rfc: high-resolution timer framework



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

Actually this was my other question. Why not replace the REALTIME timers
now?

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

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

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

Thank you for working on this!

christos



Home | Main Index | Thread Index | Old Index