From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760606AbaCULG0 (ORCPT ); Fri, 21 Mar 2014 07:06:26 -0400 Received: from fw-tnat.austin.arm.com ([217.140.110.23]:22608 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759943AbaCULGY (ORCPT ); Fri, 21 Mar 2014 07:06:24 -0400 Date: Fri, 21 Mar 2014 11:05:59 +0000 From: Catalin Marinas To: Viresh Kumar Cc: "Srivatsa S. Bhat" , "Rafael J. Wysocki" , Lists linaro-kernel , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , "ego@linux.vnet.ibm.com" Subject: Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized Message-ID: <20140321110559.GB13596@arm.com> References: <532BEE64.3090501@linux.vnet.ibm.com> <532BFB77.5060107@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 21, 2014 at 09:21:02AM +0000, Viresh Kumar wrote: > @Catalin: We have a problem here and need your expert advice. After changing > CPU frequency we need to call this code: > > cpufreq_notify_post_transition(); > policy->transition_ongoing = false; > > And the sequence must be like this only. Is this guaranteed without any > memory barriers? cpufreq_notify_post_transition() isn't touching > transition_ongoing at all.. The above sequence doesn't say much. As rmk said, the compiler wouldn't reorder the transition_ongoing write before the function call. I think most architectures (not sure about Alpha) don't do speculative stores, so hardware wouldn't reorder them either. However, other stores inside the cpufreq_notify_post_transition() could be reordered after transition_ongoing store. The same for memory accesses after the transition_ongoing update, they could be reordered before. So what we actually need to know is what are the other relevant memory accesses that require strict ordering with transition_ongoing. What I find strange in your patch is that cpufreq_freq_transition_begin() uses spinlocks around transition_ongoing update but cpufreq_freq_transition_end() doesn't. -- Catalin