LWN: Comments on "Deferrable timers"

Mask bits in pointers

proski — Fri, 30 Mar 2007 21:19:37 +0000

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

venkip — Fri, 30 Mar 2007 21:13:00 +0000

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 :-)

One pointer?

venkip — Fri, 30 Mar 2007 21:10:12 +0000

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.

One pointer?

GreyWizard — Thu, 29 Mar 2007 19:49:46 +0000

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.

Mask bits in pointers

ldo — Thu, 29 Mar 2007 08:23:42 +0000

I don't like using bits in pointers to carry extra information. That kind of thing comes back to bite you sooner or later.