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?
I think that current inplementation of del_timer_sync() don't like
add_timer_on() to
On Tue, 15 Mar 2005, Oleg Nesterov wrote:
> Christoph Lameter wrote:
> >
> > However, this also means that __run_timers will not free up the timer and
> > it has to be explicitly freed with del_timer_??.
>
> I am not sure I understand you but no, del_timer{,_sync} is not needed.
>
> __run_timer de
Christoph Lameter wrote:
>
> However, this also means that __run_timers will not free up the timer and
> it has to be explicitly freed with del_timer_??.
I am not sure I understand you but no, del_timer{,_sync} is not needed.
__run_timer deletes timer from base->tv? list and clears 'pending flag'
I like the idea and it would solve the concerns that we had. The encoding
of a bit in a pointer is weird but we have done that before in the
page_struct.
However, this also means that __run_timers will not free up the timer and
it has to be explicitly freed with del_timer_??. There may be code
tha
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
5 matches
Mail list logo
