lkml.org 
[lkml]   [2005]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/9] timer locking optimization
Roman Zippel wrote:
>
> @@ -210,6 +203,7 @@ int __mod_timer(struct timer_list *timer
>
> BUG_ON(!timer->function);
>
> +restart:
> base = lock_timer_base(timer, &flags);
>
> if (timer_pending(timer)) {
> @@ -231,11 +225,18 @@ int __mod_timer(struct timer_list *timer
> /* The timer remains on a former base */
> new_base = container_of(base, tvec_base_t, t_base);
> } else {
> - /* See the comment in lock_timer_base() */
> - timer->base = NULL;
> + /*
> + * We shortly release the timer and the timer can
> + * migrate to another cpu, so recheck the base after
> + * getting the lock.
> + */
> + timer->base = &new_base->t_base;
> spin_unlock(&base->lock);
> spin_lock(&new_base->t_base.lock);

Still not correct, I beleive.

The problem is that you are changing timer->base = &new_base->t_base
without holding new_base->t_base.lock, this is racy vs timer_del().
Suppose we are calling __mod_timer(pending_timer):

__mod_timer() locks old base, deletes the timer, changes timer's base,
unlocks old base.

Another cpu calls del_timer(). It is possible that this cpu will
see the new value of ->base == new_base before it sees changes in the
timer->entry. It locks new_base, but this is not enough, because the
timer was removed from list under the old base's lock and we don't
have a proper serialization. So it is possible that del_timer() sees
that the timer is still pending, and will try to delete it again.

In other words, in this scenario __mod_timer() and del_timer() will
take 2 different locks trying to serialize access to common data.

You can solve this with memory barriers, but this will be pessimization,
not optimization (you will also need smp_rmb in lock_timer_base()).

Honestly, personally I don'like this patch even if it was correct.
It complicates the code, and the only win is that it removes
'if (likely(base != NULL))' from the fast path, I doubt this is
noticeable.

Also, __mod_timer() becomes "non atomic", but probably this is ok.

Btw, I think you have the same problems in "[PATCH 2/9] ptimer core".

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-11-30 09:46    [W:0.175 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site