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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux