Messages in this thread | | | Date | Fri, 21 Mar 2014 11:05:59 +0000 | From | Catalin Marinas <> | Subject | Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized |
| |
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
| |