Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.

[Yunhong Jiang]

On Wed, Oct 21, 2015 at 04:16:31PM +0530, Viresh Kumar wrote:
> Cc'ing Frederic.
> 
> On 20-10-15, 15:47, Yunhong Jiang wrote:
> > On Sun, Oct 11, 2015 at 08:12:39PM +0200, Thomas Gleixner wrote:
> > > On Mon, 28 Sep 2015, Yunhong Jiang wrote:
> > > >  static void internal_add_timer(struct tvec_base *base, struct timer_list *timer)
> > > >  {
> > > > +	bool kick_nohz = false;
> > > > +
> > > >  	/* Advance base->jiffies, if the base is empty */
> > > >  	if (!base->all_timers++)
> > > >  		base->timer_jiffies = jiffies;
> > > > @@ -424,9 +426,17 @@ static void internal_add_timer(struct tvec_base *base, struct timer_list *timer)
> > > >  	 */
> > > >  	if (!(timer->flags & TIMER_DEFERRABLE)) {
> > > >  		if (!base->active_timers++ ||
> > > > -		    time_before(timer->expires, base->next_timer))
> > > > +		    time_before(timer->expires, base->next_timer)) {
> > > >  			base->next_timer = timer->expires;
> > > > -	}
> > > > +			/*
> > > > +			 * CPU in dynticks need reevaluate the timer wheel
> > > > +			 * if newer timer added with next_timer updated.
> > > > +			 */
> > > > +			if (base->nohz_active)
> > > > +				kick_nohz = true;
> > > > +		}
> > > > +	} else if (base->nohz_active && tick_nohz_full_cpu(base->cpu))
> > > > +		kick_nohz = true;
> > > 
> > > Why do you want to kick the other cpu when a deferrable timer got added?
> > 
> > This is what happens in current implementation and this patch does not 
> > change the logic. According to the comments, it's to avoid race with 
> > idle_cpu(). Frankly speaking, I didn't get the idea of the race.
> > 
> > Viresh, do you have any hints?
> 
> I haven't looked at the core since few months now and looks like I
> don't remember anything :)
> 
> This thread is where we discussed it initially:
> http://marc.info/?l=linux-kernel&m=139039035809125
> 

Viresh, thanks for the link, it's helpful.

> AFAIU, this is why we kick the other CPU for a deferrable timer:
> - The other CPU is a full-dynticks capable CPU and may be running
>   tickless and we should serve the timer in time (even if it is
>   deferrable) if the CPU isn't idle.
> - We could have saved the kick for a full-dynticks idle CPU, but a
>   race can happen where we thought the CPU is idle, but it has just
>   started serving userspace tick-lessly. And the timer wouldn't be
>   served for long time, even when the cpu was busy.

Thanks for explaination. Frederic's reply on that thread 
(http://marc.info/?l=linux-pm&m=139048414803209&w=2) also gives clear 
information.

A naive question is, why it's sure a tick will happen when the tickless 
processor is in idle? Is it because scheduler load balance is sure to send a 
tick to the processor in future?

Thanks
--jyh

> 
> Ofcourse, Frederic will kick me if I forgot the lessons he gave me
> earlier :)
> 
> -- 
> viresh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/