Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966130AbbFJPvW (ORCPT ); Wed, 10 Jun 2015 11:51:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966095AbbFJPug (ORCPT ); Wed, 10 Jun 2015 11:50:36 -0400 Date: Wed, 10 Jun 2015 17:49:33 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: umgwanakikbuti@gmail.com, mingo@elte.hu, ktkhai@parallels.com, rostedt@goodmis.org, tglx@linutronix.de, juri.lelli@gmail.com, pang.xunlei@linaro.org, wanpeng.li@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/14] hrtimer: Allow hrtimer::function() to free the timer Message-ID: <20150610154933.GA3341@redhat.com> References: <20150605084836.364306429@infradead.org> <20150605085205.723058588@infradead.org> <20150607223317.GA5193@redhat.com> <20150608091417.GM19282@twins.programming.kicks-ass.net> <20150608124234.GW18673@twins.programming.kicks-ass.net> <20150609213318.GA12436@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150609213318.GA12436@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1813 Lines: 56 Forgot to mention... On 06/09, Oleg Nesterov wrote: > > And. Note that we can rewrite these 2 "write" critical sections in > __run_hrtimer() and enqueue_hrtimer() as > > cpu_base->running = timer; > > write_seqcount_begin(cpu_base->seq); > write_seqcount_end(cpu_base->seq); > > __remove_hrtimer(timer); > > and > > timer->state |= HRTIMER_STATE_ENQUEUED; > > write_seqcount_begin(cpu_base->seq); > write_seqcount_end(cpu_base->seq); > > base->running = NULL; > > So we can probably use write_seqcount_barrier() except I am not sure > about the 2nd wmb... Or we can change hrtimer_active() to use raw_read_seqcount() likes your patch does (avoid odd/even games) and then __run_hrtimer() can use raw_write_seqcount_latch(), it already has wmb's on both sides. I am not even sure we need the "if (base->cpu_base->running == timer)" optimization for the 2nd _latch(), we cando this unconditionally in __run_hrtimer(). And in this case the code will look very much like your patch, but imo at the same it will look much more understandable. Because, again, this way we just add 2 critical "write" sections (barriers) into __run_hrtimer(), no need to explain the usage of memory barriers, etc, we can simply rely on acquire/release semantics of seqcount_t. But yes. This adds 2 additional wmb's into run_hrtimer(). Again, we can make the 2nd _latch() condtitional, we only need it if the timer requeues itself, but I am not sure. Finally. You know, I am afraid very much I confused myself completely and now I am trying to confuse you and Kirill ;) Oleg. -- 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/