Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934659AbbEMXKb (ORCPT ); Wed, 13 May 2015 19:10:31 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37307 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965349AbbEMXK1 (ORCPT ); Wed, 13 May 2015 19:10:27 -0400 Message-ID: <5553D9B4.2080806@oracle.com> Date: Wed, 13 May 2015 19:09:40 -0400 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Zijlstra CC: linux-kernel@vger.kernel.org, pjt@google.com, tglx@linutronix.de, klamm@yandex-team.ru, mingo@kernel.org, bsegall@google.com, hpa@zytor.com Subject: Re: [tip:timers/core] hrtimer: Allow concurrent hrtimer_start() for self restarting timers References: <20150415113105.GT5029@twins.programming.kicks-ass.net> <55520589.9080401@oracle.com> <20150513134311.GW21418@twins.programming.kicks-ass.net> In-Reply-To: <20150513134311.GW21418@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4973 Lines: 95 On 05/13/2015 09:43 AM, Peter Zijlstra wrote: > On Tue, May 12, 2015 at 09:52:09AM -0400, Sasha Levin wrote: >> Hey Peter, >> >> I seem to be hitting this warning with the latest -next (2015-05-11): >> >> [3344291.055800] WARNING: CPU: 0 PID: 9422 at kernel/time/hrtimer.c:802 hrtimer_forward+0x1f9/0x330() > > Indeed. > > So I can't seem to come up with a pretty solution :-( > > The 'problem' is creating a periodic timer that can stop when there's no > work left and ensuring (re)start doesn't get lost or looses overruns. > > The problem with the current code is that the re-start can come before > the callback does fwd, at which point the fwd will spew the above > warning (rightly so). > > Now, conceptually its easy to detect if you're before or after the fwd > by comparing the expiration time against the current time. Of course, > that's expensive (and racy) because we don't have the current time. > > Alternatively one could cache this state inside the timer, but then > everybody pays the overhead of maintaining this extra state, and that is > undesired. > > The only other option that I could see is the external timer_active > variable, which I tried to kill before. > > So I suppose the below (compile tested) patch should fix things, but > seeing how I've been up since 4am I might just have missed something > obvious :-) I know exactly how you feel... > Almost-Signed-off-by: Peter Zijlstra (Intel) Original warning is gone, but now I get: [ 281.213520] INFO: trying to register non-static key. [ 281.214251] the code is fine but needs lockdep annotation. [ 281.214251] turning off the locking correctness validator. [ 281.214251] CPU: 0 PID: 10071 Comm: trinity-main Tainted: G W 4.1.0-rc3-next-20150512-sasha-00051-gd40f47b-dirty #2213 [ 281.214251] ffffffffae4a5b20 00000000cbbe31dc ffff88000267f698 ffffffffa7c8e8ab [ 281.214251] 0000000000000000 0000000000000000 ffff88000267f848 ffffffff9e303567 [ 281.214251] ffff88001d015260 0000000000000004 ffff88001d014d20 0000000000000005 [ 281.214251] Call Trace: [ 281.214251] dump_stack (lib/dump_stack.c:52) [ 281.214251] __lock_acquire (kernel/locking/lockdep.c:786 kernel/locking/lockdep.c:3134) [ 281.214251] ? x86_schedule_events (arch/x86/kernel/cpu/perf_event.c:849 (discriminator 2)) [ 281.214251] ? lockdep_reset_lock (kernel/locking/lockdep.c:3105) [ 281.214251] ? x86_pmu_commit_txn (arch/x86/kernel/cpu/perf_event.c:1098) [ 281.214251] ? x86_pmu_commit_txn (arch/x86/kernel/cpu/perf_event.c:1731) [ 281.214251] ? x86_pmu_cancel_txn (arch/x86/kernel/cpu/perf_event.c:1720) [ 281.214251] ? perf_event_update_userpage (include/linux/rcupdate.h:917 kernel/events/core.c:4256) [ 281.214251] lock_acquire (kernel/locking/lockdep.c:3658) [ 281.214251] ? perf_mux_hrtimer_restart (kernel/events/core.c:807) [ 281.214251] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:119 kernel/locking/spinlock.c:159) [ 281.214251] ? perf_mux_hrtimer_restart (kernel/events/core.c:807) [ 281.214251] perf_mux_hrtimer_restart (kernel/events/core.c:807) [ 281.214251] group_sched_in (kernel/events/core.c:1963) [ 281.214251] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 281.214251] ctx_sched_in (kernel/events/core.c:2725 kernel/events/core.c:2756) [ 281.214251] perf_event_sched_in (kernel/events/core.c:2025) [ 281.214251] __perf_install_in_context (kernel/events/core.c:2082) [ 281.214251] ? perf_mux_hrtimer_handler (kernel/events/core.c:2035) [ 281.214251] remote_function (kernel/events/core.c:74) [ 281.214251] ? pmu_dev_release (kernel/events/core.c:66) [ 281.214251] generic_exec_single (kernel/smp.c:157) [ 281.214251] ? pmu_dev_release (kernel/events/core.c:66) [ 281.214251] smp_call_function_single (kernel/smp.c:300) [ 281.214251] ? generic_exec_single (kernel/smp.c:273) [ 281.214251] ? __lock_is_held (kernel/locking/lockdep.c:3572) [ 281.214251] task_function_call (kernel/events/core.c:101) [ 281.214251] ? remote_function (kernel/events/core.c:92) [ 281.214251] ? perf_mux_hrtimer_handler (kernel/events/core.c:2035) [ 281.214251] perf_install_in_context (kernel/events/core.c:2121) [ 281.214251] ? add_event_to_ctx (kernel/events/core.c:2102) [ 281.214251] ? alloc_perf_context (kernel/events/core.c:3306) [ 281.214251] ? perf_event_alloc (kernel/events/core.c:7569) [ 281.214251] SYSC_perf_event_open (kernel/events/core.c:8133) [ 281.214251] ? perf_event_alloc (kernel/events/core.c:7856) [ 281.214251] ? syscall_trace_enter_phase1 (include/linux/context_tracking.h:27 arch/x86/kernel/ptrace.c:1480) [ 281.214251] SyS_perf_event_open (kernel/events/core.c:7853) [ 281.214251] tracesys_phase2 (arch/x86/kernel/entry_64.S:346) Thanks, Sasha -- 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/