[PATCH 0/2] del_timer_sync: proof of concept

From: Oleg Nesterov
Date: Tue Mar 15 2005 - 11:16:56 EST

Andrew Morton wrote:
> If we're prepared to rule that a timer handler is not allowed to do
> add_timer_on() then a recurring timer is permanently pinned to a CPU, isn't
> it?
> That should make things simpler?

In that case I think that both problems (race and scalability)
can be solved without increasing sizeof(timer_list).

What if timer_list had ->pending field? Then we can do:

return timer->pending;

internal_add_timer(new_base, timer);
timer->base = new_base;
timer->pending = 1;

set_running_timer(base, timer);

/* do not change timer->base */
timer->pending = 0;


if (!timer->pending)
return 0;
base = timer->base;

base = timer->base;
if (!base)
return 0;

if (base != timer->base)
goto del_again;
if (base->running_timer == timer)
goto del_again;

if (timer->pending)

timer->pending = 0;
timer->base = NULL;

The ->pending flag could live in the least significant bit of
timer->base, this way we:
1. do not waste the space
2. can read/write base+pending atomically

These patches are incomplete/suboptimal, just a proof of concept.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/