Adding Rainer as well On 15 November 2013 13:45, Lan Tianyu <tianyu.lan@xxxxxxxxx> wrote: > Currently, governor of nonboot cpus will be put to EXIT when system suspend. > Since all these cpus will be unplugged and the governor usage_count decreases > to zero. The governor data and its sysfs interfaces will be freed or released. > This makes user config of these governors loss during suspend and resume. > > This doesn't happen on the governor covering boot cpu because it isn't > unplugged during system suspend. > > To fix this issue, skipping governor exit during system suspend and check > policy governor data to determine whether the governor is really needed > to be initialized when do init. If not, return EALREADY to indicate the > governor has been initialized and should do nothing. __cpufreq_governor() > convert EALREADY to 0 as return value for INIT event since governor is > still under INIT state and can do START operation. Though the patch I have sent fixes a problem similar to this but I don't think patch of any of us will solve the issue Rainer is facing.. I checked his system configuration and its like this: - Four CPUs, all having separate clock domains (atleast from kernel perspective) and so separate policy structure. - All are using ondemand governor - not using CPUFREQ_HAVE_GOVERNOR_PER_POLICY feature - So there is a single set of tunables for ondemand governor that is applicable across all CPUs.. The way INIT/EXIT are designed in cpufreq_governor.c should take care of this scenario. memory for tunables must not be freed unless all the CPUs are removed. Which can't happen, as we only offline non-boot CPUs and so I believe that memory isn't getting freed and so your solution wouldn't address his problem.. Sorry if I said something stupid enough :) -- viresh -- 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
