Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752796AbaKLNzF (ORCPT ); Wed, 12 Nov 2014 08:55:05 -0500 Received: from mail-wi0-f178.google.com ([209.85.212.178]:42592 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752278AbaKLNzD (ORCPT ); Wed, 12 Nov 2014 08:55:03 -0500 Date: Wed, 12 Nov 2014 14:54:58 +0100 From: Frederic Weisbecker To: Viresh Kumar Cc: Christoph Lameter , "Paul E. McKenney" , Thomas Gleixner , Linux Kernel Mailing List , Gilad Ben-Yossef , Tejun Heo , John Stultz , Mike Frysinger , Minchan Kim , Hakan Akkan , Max Krasnyansky , Hugh Dickins , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Kevin Hilman Subject: Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment) Message-ID: <20141112135455.GA6895@lerouge> References: <20141110153147.GK4901@linux.vnet.ibm.com> <20141111171526.GC3216@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 12, 2014 at 11:41:09AM +0530, Viresh Kumar wrote: > On 11 November 2014 22:45, Frederic Weisbecker wrote: > > > Here is a summarized list: > > > > * Unbound workqueues affinity (to housekeeper) > > * Unbound timers affinity (to housekeeper) > > * 1 Hz residual scheduler tick offlining to housekeeper > > * Fix some scheduler accounting that don't even work with 1 Hz: cpu load > > accounting, rt_scale, load balancing, etc... > > * Lighten the syscall path and get rid of cputime accounting + RCU hooks > > for people who want isolation + fast syscalls and faults. > > * Work on non-affinable workqueues > > * Work on non-affinable timers > > * ... > > + spurious interrupts with NOHZ_FULL on all architectures which break isolation > but doesn't get caught with traces. Can be observed with this: > > diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c > index 481fa54..91d490d 100644 > --- a/kernel/time/hrtimer.c > +++ b/kernel/time/hrtimer.c > @@ -1244,7 +1244,8 @@ void hrtimer_interrupt(struct clock_event_device *dev) > { > struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases); > ktime_t expires_next, now, entry_time, delta; > - int i, retries = 0; > + int i, retries = 0, count = 0; > + static int total_spurious; > > BUG_ON(!cpu_base->hres_active); > cpu_base->nr_events++; > @@ -1304,10 +1305,14 @@ void hrtimer_interrupt(struct clock_event_device *dev) > break; > } > > + count++; > __run_hrtimer(timer, &basenow); > } > } > > + if (!count) > + pr_err("____%s: Totalspurious: %d\n", __func__, > ++total_spurious); > + I'd rather leave that to tracepoints. Like trace_hrtimer_spurious(). Or better yet: have trace_hrtimer_interrupt() which we can compare against trace_hrtimer_expire_entry/exit() to check if any hrtimer callback have run in the interrupt. This way we avoid workarounds like the above count. > /* > * Store the new expiry value so the migration code can verify > * against it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/