On 09/12/2013 12:11 PM, Viresh Kumar wrote: > On 12 September 2013 11:56, Srivatsa S. Bhat > <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: >> I had the same thought when solving this bug.. We have had similar issues with >> CPU hotplug notifiers too: why are they invoked in the same order during both >> CPU down and up, instead of reversing the order? I even had a patchset to perform >> reverse-invocation of notifiers.. http://lwn.net/Articles/508072/ >> ... but people didn't find that very compelling to have. >> > >> It does to me too, but I think the reason nobody really bothered is because perhaps >> not many other subsystems care about the order in which CPUs are torn down or >> brought up; they just need the total number to match.. cpufreq is one exception >> as we saw with this bug. > > Probably its time to re-spin that series and make CPUFreq as one of the users > of that patchset.. Resume should be just opposite of suspend and so > that patchset > would make sense even if not many people care about it :) > > Over that there is one more problem that I see, don't know if it is really a big > issue.. > > After a suspend/resume value of policy->cpu may get changed... And so the > hierarchy of sysfs cpufreq files too.. Folder that had links to other > CPUs folder > can now be actual folders instead of links and vice versa.. > > Don't know if this can break something ?? > Interesting observation :-) But we just managed to retain sysfs file permissions across suspend/resume with a lot of trouble and regressions. That's probably good enough for some time to come ;-) We can retain folder/links when somebody really finds a need to do that ;-) Of course, if we change the suspend/resume sequence and that fixes this, that would be like getting it for free, nobody would say no to it ;-) Regards, Srivatsa S. Bhat -- 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
