Just to elaborate on why I don't think this is possible: By adding something like Lets assume 2 processes are currently running with PIDs 1000, 2000. I'm using '->' to signal a context switch and 500 to denote the workqueue work. We could very well end up with something like: 1000 -> 2000 -> 500 (to set for PID 2000) -> 1000 -> 500 (to set for PID 1000) -> 2000 -> 500 (to set for PID 2000) ... ... .. Regards Guru On Tue, Aug 18, 2015 at 9:05 AM, Guru Prasad <gurupras@xxxxxxxxxxx> wrote: > I don't think this will allow me to have a per-process frequency setting. > > The problem I see with this approach is that, the scheduled work is > run in its own context, which means there will be a context switch. > When this happens, another instance of the work will be scheduled > (from schedule() ). I imagine I would need a conditional call to > schedule_work(). Something like: > if(!is_kthread(next)) > schedule_work(...); > > Regards > Guru > > > On Tue, Aug 18, 2015 at 6:27 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: >> On Tue, Aug 18, 2015 at 9:16 AM, Guru Prasad <gurupras@xxxxxxxxxxx> wrote: >>> We're working on a research system where we're trying to achieve >>> optimal frequency selection on a per-process basis. To do so, I added >>> additional fields to struct task_struct to store the (computed) >>> optimal frequency and set it. The code that computes the optimal >>> frequency is calculated on every scheduler_tick(). >>> >>> I'm having trouble calling cpufreq_set_rate() from both a) >>> scheduler_tick() and b) schedule(). >> >> Its not just about mutex-lock. The two scheduler functions mentioned above >> are called from atomic context, but they can't call anything which can >> potentially >> sleep. >> >> cpufreq_set_rate() or any clk_rate_set() can potentially sleep, and so must >> not be called from there. Best do it from a workqueue. >> >> -- >> 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
