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:
timer_pending:
return timer->pending;
__mod_timer:
internal_add_timer(new_base, timer);
timer->base = new_base;
timer->pending = 1;
__run_timers:
list_del(&timer->entry);
set_running_timer(base, timer);
/* do not change timer->base */
timer->pending = 0;
spin_unlock(base->lock);
timer->function();
del_timer:
if (!timer->pending)
return 0;
base = timer->base;
...
del_timer_sync:
base = timer->base;
if (!base)
return 0;
spin_lock(base->lock);
if (base != timer->base)
goto del_again;
if (base->running_timer == timer)
goto del_again;
if (timer->pending)
list_del(&timer->entry);
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.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
