From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbbBXAxK (ORCPT ); Mon, 23 Feb 2015 19:53:10 -0500 Received: from pmta1.delivery3.ore.mailhop.org ([54.191.214.36]:57101 "EHLO pmta1.delivery3.ore.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752559AbbBXAxH (ORCPT ); Mon, 23 Feb 2015 19:53:07 -0500 X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 104.193.169.186 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+mvu2DUl8ciMMImH6aLonc Date: Mon, 23 Feb 2015 16:38:49 -0800 From: Tony Lindgren To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, rjw@rjwysocki.net, tglx@linutronix.de, Fenghua Yu , Len Brown , Daniel Lezcano Subject: Re: [PATCH 12/35] clockevents: Provide explicit broadcast control function Message-ID: <20150224003848.GL32521@atomide.com> References: <20150216121435.203983131@infradead.org> <20150216122412.676635392@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150216122412.676635392@infradead.org> 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 * Peter Zijlstra [150216 05:13]: > From: Thomas Gleixner > > clockevents_notify() is a leftover from the early design of the > clockevents facility. It's really not a notification mechanism, it's a > multiplex call. We are way better off to have explicit calls instead of this > monstrosity. > > Split out the broadcast control into a separate function and provide > inline helpers. Switch clockevents_notify() over. This will go away > once all callers are converted. > > This also gets rid of the nested locking of clockevents_lock and > broadcast_lock. The broadcast control functions do not require > clockevents_lock. Only the managing functions > (setup/shutdown/suspend/resume of the broadcast device require > clockevents_lock. Seems to still behave for my off-idle PM tests after a quick try on Peter's timers/core branch. Might be too late, but just in case it's not: Tested-by: Tony Lindgren