http://lwn.net/Articles/228143/ This is a special feed containing comments posted to the individual LWN article titled "Deferrable timers". hourly 2 http://lwn.net/Articles/228690/rss 2007-03-30T21:19:37+00:00 proski 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. http://lwn.net/Articles/228689/rss 2007-03-30T21:13:00+00:00 venkip <p> 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 :-)<br> http://lwn.net/Articles/228686/rss 2007-03-30T21:10:12+00:00 venkip <p> 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.<br> http://lwn.net/Articles/228481/rss 2007-03-29T19:49:46+00:00 GreyWizard 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.<br> http://lwn.net/Articles/228302/rss 2007-03-29T08:23:42+00:00 ldo I don't like using bits in pointers to carry extra information. That kind of thing comes back to bite you sooner or later.