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