On 22-05-18, 15:09, Joel Fernandes wrote: > I agree with the race you describe for single policy slow-switch. Good find :) > > The mainline sugov_work could also do such reordering in sugov_work, I think. > Even > with the mutex_unlock in mainline's sugov_work, that work_in_progress write > could > be reordered by the CPU to happen before the read of next_freq. AIUI, > mutex_unlock is expected to be only a release-barrier. > > Although to be safe, I could just put an smp_mb() there. I believe with that, > no locking would be needed for such case. > > I'll send out a v3 with Acks for the original patch, and the send out the > smp_mb() as a separate patch if that's Ok.
Maybe it would be better to get the fix (with smp_mb) first and then this optimization patch on the top? That would mean that the fix can get applied to stable kernels easily. -- viresh
