Re: Changing CPU frequency in atomic (schedule / scheduler_tick)

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 <[email protected]> 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 <[email protected]> wrote:
>> On Tue, Aug 18, 2015 at 9:16 AM, Guru Prasad <[email protected]> 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