Guru Prasad <gurupras@xxxxxxxxxxx> writes: > 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) ... ... .. Changing frequency involves latency which varies across different platforms. Often times the latencies are of the order of ms (while the PMICs change voltages and stabilise, the clocks are updated, and all over slow data rate buses from the cpu). Depending on the platform, the latency is either visible to the kernel or handled by the firmware. When the latencies are visible to the kernel, you don't want to block forward progress of the task while the frequency is changing (imagine waiting 1ms to change frequency for a task that will run for 1-2ms). So that is a bit of a hand-wavy reason for why the frequency change is hard to do from scheduler context without delegating it to a worker of sorts. Hope that helps. The thread Viresh pointed to in this thread has a new posting recently[0] - though it is very likely taking the same approach - using a high priority task to effect the change where the platform doesn't hide latency from the kernel. [0] http://thread.gmane.org/gmane.linux.power-management.general/69176 > > > 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 -- 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
