Messages in this thread | | | Date | Wed, 30 Nov 2005 21:17:29 +0300 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/9] timer locking optimization |
| |
Roman Zippel wrote: > > Hi, > > On Wed, 30 Nov 2005, Oleg Nesterov wrote: > > > Still not correct, I beleive. > > Here is a new idea, what do you think about using spin_trylock(), e.g. > something like: > > if (spin_trylock(&new_base->t_base.lock)) { > timer->base = &new_base->t_base; > spin_unlock(&base->lock); > } else > new_base = container_of(base, tvec_base_t, t_base); > > It's not like we must start the timer on the current cpu and this might > even be faster. If the new base is busy on another cpu, it's possible we > have to pull dirty cache lines from the other cpu, where we might already > have the data from the current base already in the cache from the detach.
... and this will simplify the code! I think this is a nice idea. Something like this:
if (base != &new_base->t_base) {
if (unlikely(base->running_timer == timer) || !spin_trylock(&new_base->t_base.lock)) { /* The timer remains on a former base */ new_base = container_of(base, tvec_base_t, t_base); } else { timer->base = &new_base->t_base; spin_unlock(&base->lock); } }
But please update comments too, and don't forget to cc Ingo and Andrew at least. In my opinion this patch should go separately from other ptimer patches.
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/
| |