| |||||||||||||
Mask bits in pointersMask bits in pointersPosted Mar 29, 2007 8:23 UTC (Thu) by ldo (subscriber, #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.
(Log in to post comments)
One pointer? Posted Mar 29, 2007 19:49 UTC (Thu) by GreyWizard (guest, #1026) [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? Posted Mar 30, 2007 21:10 UTC (Fri) by venkip (subscriber, #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.
Mask bits in pointers Posted Mar 30, 2007 21:13 UTC (Fri) by venkip (subscriber, #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 :-)
Mask bits in pointers Posted Mar 30, 2007 21:19 UTC (Fri) by proski (subscriber, #104) [Link] 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.
|
|||||||||||||