From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753494AbbDBN7r (ORCPT ); Thu, 2 Apr 2015 09:59:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50846 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753113AbbDBN6j (ORCPT ); Thu, 2 Apr 2015 09:58:39 -0400 Message-ID: <551D4B02.30302@redhat.com> Date: Thu, 02 Apr 2015 09:58:26 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Marcelo Tosatti , Frederic Weisbecker CC: linux-kernel@vger.kernel.org, Thomas Gleixner , "Paul E. McKenney" , Viresh Kumar Subject: Re: kernel/timer: avoid spurious ksoftirqd wakeups References: <20150402014455.GA25970@amt.cnet> In-Reply-To: <20150402014455.GA25970@amt.cnet> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/01/2015 09:44 PM, Marcelo Tosatti wrote: > +++ 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; You may want to initialize this to false. Nothing else in the code ever seems to set it to false. It may work in your test due to that address on the stack already being zeroed out due to a lucky coincidence, but that is not a guarantee. > --- a/kernel/time/timer.c > +++ b/kernel/time/timer.c > @@ -1343,7 +1343,7 @@ static unsigned long cmp_next_hrtimer_event(unsigned long now, > * get_next_timer_interrupt - return the jiffy of the next pending timer > * @now: current time (in jiffies) > */ > -unsigned long get_next_timer_interrupt(unsigned long now) > +unsigned long get_next_timer_interrupt(unsigned long now, bool *raise_softirq) > { > struct tvec_base *base = __this_cpu_read(tvec_bases); > unsigned long expires = now + NEXT_TIMER_MAX_DELTA; > @@ -1357,6 +1357,7 @@ unsigned long get_next_timer_interrupt(unsigned long now) > > spin_lock(&base->lock); > if (base->active_timers) { > + *raise_softirq = true; > if (time_before_eq(base->next_timer, base->timer_jiffies)) > base->next_timer = __next_timer_interrupt(base); > expires = base->next_timer; Given that run_timer_softirq() only actually does something if the timer has expired, would it make sense to only raise the softirq after the timer has expired?