On Sunday 31 May 2009 18:23:01 Mathieu Desnoyers wrote: > * Shaohua Li (shaohua.li@xxxxxxxxx) wrote: > > commit b14893a62c73af0eca414cfed505b8c09efc613c tries to address a lockdep > > issue, but it introduces new deadlock when doing governor switching. > > > > store(lock_policy_rwsem_write)->store_scaling_governor->__cpufreq_set_policy-> > > cpufreq_governor_dbs->dbs_timer_exit->cancel_delayed_work_sync(hold fake work lock) > > > > but when the dbs work runs: run_workqueue(hold fake work lock)->do_dbs_timer(lock_policy_rwsem_write) > > > > I didn't find an easy way to fix this deadlock, hopes your guys have. > > > > Argh, why is this lock_policy_rwsem_write so pervasive ? It seems like > it is taken about everywhere before calling any cpufreq code, even when > not needed. I'd recommend to clearly identify the sites where policy > modification is done and only take the rwsem _there_. Otherwise, we end > up in a chicked and egg problem with timer teardown, where we workqueue > lock has to be taken outside of the read-lock (in the worker thread) and > inside of the lock (in the rwsem code). > > That's really odd. Locking in cpufreq subsystem always is/was a nightmare. I brought this up already and there were not much objections: Can we reduce complexity and disallow different governors on different cores? If you really want to have a specific amount of cores running at full performance depending on whatever (or whatever else you want to achieve), you can write/implement a separate governor and configure it via sysfs files. Not sure whether it helps here, but I remember this would ease up locking at different places and make things much easier and less error-prone. Thomas -- 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
