Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753313AbbFHRL5 (ORCPT ); Mon, 8 Jun 2015 13:11:57 -0400 Received: from www.linutronix.de ([62.245.132.108]:42682 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751878AbbFHRLt (ORCPT ); Mon, 8 Jun 2015 13:11:49 -0400 Date: Mon, 8 Jun 2015 19:11:25 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Oleg Nesterov , umgwanakikbuti@gmail.com, mingo@elte.hu, ktkhai@parallels.com, rostedt@goodmis.org, juri.lelli@gmail.com, pang.xunlei@linaro.org, wanpeng.li@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] hrtimer: HRTIMER_STATE_ fixes In-Reply-To: <1433777745.1495.41.camel@twins> Message-ID: References: <20150605084836.364306429@infradead.org> <20150605085205.723058588@infradead.org> <20150607223317.GA5193@redhat.com> <20150608091417.GM19282@twins.programming.kicks-ass.net> <20150608141709.GX18673@twins.programming.kicks-ass.net> <20150608151039.GA23138@redhat.com> <1433777745.1495.41.camel@twins> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 34 On Mon, 8 Jun 2015, Peter Zijlstra wrote: > On Mon, 2015-06-08 at 17:10 +0200, Oleg Nesterov wrote: > > On 06/08, Peter Zijlstra wrote: > > > > > > > I tend to agree, but I think its a pre-existing problem, not one > > > > introduced by my proposed patch. > > > > > > Something like this would fix that I think. It fully preserves > > > timer->state over hrtimer_start_range_ns(). > > > > Yes, but I think we can do a bit better. > > > > Only for initial review, I need to re-check this... > > I'm having a wee bit of bother spotting how you version is 'better'. > > > And. I think that after you remove STATE_CALLBACK we can even kill > > timer->state altogether, but this is another story. > > Ah, yes, we could introduce timerqueue_is_queued() which uses > RB_EMPTY_NODE(). Obviating the need for hrtimer::state entirely. Which won't work for the migration case unless we have some trickery like we do with double linked lists (not setting the prev member to NULL on dequeue). Thanks, tglx -- 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/