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