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.