mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org, Rik van Riel <riel@redhat.com>
Subject: Re: kernel/timer: avoid spurious ksoftirqd wakeups (v2)
Date: Tue, 7 Apr 2015 23:10:49 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1504072200210.3845@nanos> (raw)
In-Reply-To: <20150406231557.GA5094@amt.cnet>

On Mon, 6 Apr 2015, Marcelo Tosatti wrote:
> It is only necessary to raise timer softirq
> in case there are active timers.

Depends. See below.
 
> Limit the ksoftirqd wakeup to that case.
> 
> Fixes a latency spike with isolated CPUs and
> nohz full mode.

This lacks a proper explanation of the observed issue.

> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -568,6 +568,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
>  	unsigned long rcu_delta_jiffies;
>  	struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev);
>  	u64 time_delta;
> +	bool raise_softirq = false;

This shadows the function name raise_softirq(). Not pretty.
  
>  	time_delta = timekeeping_max_deferment();
>  
> @@ -584,7 +585,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
>  		delta_jiffies = 1;
>  	} else {
>  		/* Get the next timer wheel timer */
> -		next_jiffies = get_next_timer_interrupt(last_jiffies);
> +		next_jiffies = get_next_timer_interrupt(last_jiffies,
> +							&raise_softirq);
>  		delta_jiffies = next_jiffies - last_jiffies;
>  		if (rcu_delta_jiffies < delta_jiffies) {
>  			next_jiffies = last_jiffies + rcu_delta_jiffies;
> @@ -703,7 +705,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
>  		 */
>  		tick_do_update_jiffies64(ktime_get());
>  	}
> -	raise_softirq_irqoff(TIMER_SOFTIRQ);
> +	if (raise_softirq)
> +		raise_softirq_irqoff(TIMER_SOFTIRQ);

This breaks when high resolution timers are disabled (compile or
runtime) because then the hrtimer queues are run from the timer
softirq.

Now assume the following situation:

  Tick is stopped completely with no timers and no hrtimers pending.

  Interrupt happens and schedules a hrtimer.

  nohz_stop_sched_tick()
    get_next_timer_interrupt(..., &raise_softirq);

      ---> base->active_timers = 0, so raise_softirq is false

    tick_program_event(expires)
      clockevents_program_event(expires)
      
      ---> Assume expires is already in the past

        if (expires <= ktime_get())
	   return -ETIME;

    if (raise_softirq)
       raise_softirq_irqoff(TIMER_SOFTIRQ);

So because the tick device was not armed you wont get a tick
interrupt up to the point where tick_nohz_stop_sched_tick() is called
again which might be far off.

I can see that the unconditional raise_softirq_irqoff() is suboptimal,
but it was a rather simple solution to get stuff rolling again because
it forces the cpu out of the inner idle loop which in turn restarts
the tick.

We certainly can do better, but that needs more thought than the
proposed solution.

Thanks,

	tglx

  parent reply	other threads:[~2015-04-07 21:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 23:15 Marcelo Tosatti
2015-04-06 23:20 ` Rik van Riel
2015-04-07 21:10 ` Thomas Gleixner [this message]
2015-04-07 22:12   ` Frederic Weisbecker
2015-04-10 18:09     ` Marcelo Tosatti
2015-04-11  1:30       ` Luiz Capitulino
2015-04-11  9:25         ` Thomas Gleixner
2015-04-13 15:06           ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1504072200210.3845@nanos \
    --to=tglx@linutronix.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®