Re: [PATCH 1/9] timer locking optimization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux