Mask bits in pointers
Mask bits in pointers
Posted Mar 29, 2007 8:23 UTC (Thu) by ldo (guest, #40946)Parent article: Deferrable timers
I don't like using bits in pointers to carry extra information. That kind of thing comes back to bite you sooner or later.
Posted Mar 29, 2007 19:49 UTC (Thu)
by GreyWizard (guest, #1026)
[Link] (1 responses)
Posted Mar 30, 2007 21:10 UTC (Fri)
by venkip (guest, #37888)
[Link]
The current timer infrastructure and the changes done is for per CPU timers. That is each CPU looks at all the timers scheduled on it independently. So, such a pointer has to be atleast per CPU. Cost of such a pointer is that we will have to go through timer wheel to find next non-deferrable timer and more importantly, we have to have different set of interfaces for these deferrable and non-deferrable or have extra space in timer structure to indicate the nature of timer so that this pointer can be updated correctly when one non-deferrable tiemr expires.
Posted Mar 30, 2007 21:13 UTC (Fri)
by venkip (guest, #37888)
[Link]
Thing to note is that the pointers being reused are pointer to a per CPU structure that doesnt change over time. This structure is allocated at boot time and stays same. So, risk of coming back to biting me is slightly smaller :-)
Posted Mar 30, 2007 21:19 UTC (Fri)
by proski (subscriber, #104)
[Link]
Why not keep a single, system-wide pointer to the next non-deferable timer? This would have to be maintained each time such a timer fires but the cost might be comparable to all the masking and the resulting code might be easier to understand and maintain.One pointer?
One pointer?
Mask bits in pointers
Casting a pointer to unsigned int would cause at least a warning on 64-bit systems. And I'm not convinced that avoiding an extra field in struct tvec_t_base_s by using pointer arithmetics would offer any advantage either in memory requirements or in speed.
Mask bits in pointers