On 14 October 2014 17:12, Prarit Bhargava prarit@redhat.com wrote:
I've been running both my test and Robert's test for about 5 mins. In Robert's case I don't see any problems ... in my case I do occasionally get a system panic because of the sysfs access race I described in the other thread (cpu 1 holds a sysfs file open, while cpu 2 changes the governor ...)
Can you give me the exact script? I wasn't able to reproduce it.
I do have some concerns about the nature of this patchset; I feel it is more of a band-aid approach to the whole cpufreq mechanism. Having said that, I haven't offered an alternative yet so I can't really object too loudly :)
Yes and No. Some part of it is indeed required. For example, checking for a valid operation must be performed in __cpufreq_governor(). Its not just called from cpufreq_set_policy() but other places as well.. And so accepting STOP from one thread and maybe START from other will always be a problem.
About serializing calls to __cpufreq_governor(), yes a lock will be a better fix. But we have a long standing issue with that. And I am not able to generate the lockdep for some reason now.
-- viresh