On Mon, May 13, 2013 at 8:19 AM, Xiaoguang Chen <chenxg.marvell@xxxxxxxxx> wrote: > Hi, Cpufreq Guys > > We meet one race condition for cpufreq governor start/stop during > hotplug and manually governor change. > > we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0. > the normal sequence is as below: > > 1) Current governor is userspace, one application tries to set > governor to ondemand. it will call __cpufreq_set_policy in which it > will stop userspace governor and then start ondemand governor. > > 2) Current governor is userspace, now cpu0 hotplugs in cpu3, it will > call cpufreq_add_policy_cpu. on which it first stop governor > userspace, and then start governor userspace. > > > Now if the sequence of abover two cases interleaves, it becames below sequence: > > 1) application stops userspace governor > 2) > hotplug stops userspace governor > 3) application starts ondemand governor > 4) > hotplug starts a governor > > in step 4, hotplug is supposed to start userspace governor, but now > the governor has been changed by application to ondemand, so hotplug > starts ondemand governor again !!!! > > there are some consequences for this issue: > ondemand governor will be started for multi-times which causes its > timer be inialized multitimes, if we use object debug to trace this, > we get a waring that the timer object is alive but it is initialized > again. > > > The issue happens because we use one same cpufreq policy for all cpus, > once the policy is changed, all cpus will be affected. I tried to add > a mutex lock before governor stop and after governor start. but it > cannot solve the problem completely as there maybe some other places > that changes the cpufreq policy, if it doesn't use the same mutex > lock, policy may still be changed during stop/start sequence. the > final governor may still not the expected one. > > Do we have some discussion for this issue before ? any suggestions for this? We never had a discussion on this earlier and on the face of it, it looks like a locking issue which must be fixed. I am not sure if i would be able to devote some time on it right now as i just came back from 15 days leave and have a lot of stuff to finish. If you can provide a patch, i can surely review it quickly. :) -- 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
