From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized Date: Fri, 21 Mar 2014 11:05:59 +0000 Message-ID: <20140321110559.GB13596@arm.com> References: <532BEE64.3090501@linux.vnet.ibm.com> <532BFB77.5060107@linux.vnet.ibm.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: cpufreq-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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" 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