On 30 January 2013 22:16, Fabio Baltieri <fabio.baltieri@xxxxxxxxxx> wrote: > Isn't that how it works now? The current cpu ktime is not checked > against its own, but against the "leader" cpu (dbs_info_local->cdbs.cpu), > that's why it's initialized only for the first. > > Maybe I should have used dbs_info_leader/dbs_info instead of > dbs_info_local/dbs_info. This routine is called as wq handler. Which will recover dbs_info from work using container_of. Which would give dbs_info_local for the cpu j. Then we will execute below code. + /* use leader CPU's dbs_info */ + dbs_info = &per_cpu(od_cpu_dbs_info, dbs_info_local->cdbs.cpu); dbs_info_local->cdbs.cpu was uninitialized for all cpus except policy->cpu. And so, might be initialized with 0 as its a global variable... But if you offline cpu 0 and online it back, then policy->cpu would be 1 and this logic, which worked by mistake will fail. + mutex_lock(&dbs_info->cdbs.timer_mutex); + + time_now = ktime_get(); + delta_us = ktime_us_delta(time_now, dbs_info->cdbs.time_stamp); and so as this. Correct? -- 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
