On 21 March 2014 16:35, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > 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. I got confused again. If we see what cpufreq_notify_post_transition() does: Just calling a list of routines from a notifiers chain. And going by the above statements from you, we aren't going to reorder this with function calls or a branch instructions. And even if for some reason, there is a bit of reorder, it doesn't look harmless at all to me. We are more concerned about serialization of frequency translations here. And it still looks to me like we don't really need a barrier at all.. Probably we can keep it as is for now and maybe later add a barrier if required. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
