lkml.org 
[lkml]   [2005]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[PATCH 0/2] del_timer_sync: proof of concept
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:11    [from the cache]
©2003-2011 Jasper Spaans