From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752629AbbCQHY6 (ORCPT ); Tue, 17 Mar 2015 03:24:58 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:55483 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbbCQHY5 (ORCPT ); Tue, 17 Mar 2015 03:24:57 -0400 Date: Tue, 17 Mar 2015 08:24:51 +0100 From: Peter Zijlstra To: Preeti U Murthy Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, Ingo Molnar Subject: Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in idle loop Message-ID: <20150317072451.GO2896@worktop.programming.kicks-ass.net> References: <20150226032202.20019.91636.stgit@preeti.in.ibm.com> <20150302145354.GM21418@twins.programming.kicks-ass.net> <54F7DD4E.1000100@linux.vnet.ibm.com> <20150316145610.GF21418@twins.programming.kicks-ass.net> <5507AB61.90907@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5507AB61.90907@linux.vnet.ibm.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 17, 2015 at 09:49:45AM +0530, Preeti U Murthy wrote: > Ok I see your point now. Sorry about having misinterpreted it > previously. ce_broadcast_hrtimer is not the per-cpu clock device. It is > not a real clock device. It is a pseudo clock device, which is called > only from the guts of the broadcast framework. > When it is programmed, it queues a hrtimer and programs the per-cpu > clock device. in the fashion mentioned above. > > No hrtimer programming/starting/canceling will get routed through > bc_set_next(). The broadcast framework makes use of a separate broadcast > clock device, which is never the per-cpu clock device to wake cpus from > idle. This device is programmed explicitly when required and not > indirectly via timer queueing. *Only* when this broadcast clock device > needs to reprogrammed, bc_set_next() gets called on those archs which > *do not have a real broadcast clock device*. And the whole thing kicks > in when cpus go idle only, not just for PowerPC but for ARM as well. Ah, I see, tick_check_new_device() will never select it. CLOCK_EVT_FEAT_PERCPU seems a rather pointless thing though, maybe a remnant of something gone. OK now it makes sense.. some of this could use a few comments, but I suppose that's true of most things ;-)