Re: [RFC] Unprepare callback for cpuidle_device

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

 



hello Deepthi,
          please see my replies inline:


> Hi Amar,
>
> On Friday 08 July 2011 01:22 AM, asinghal@xxxxxxxxxxxxxx wrote:
>> Hello Trinabh,
>>               i cannot use the enter callback due to the following
>> reason:
>>
>> the residency calculation(tick)nohz_get_sleep_length) and the idle state
>> selection happens in the menu governor. The enter callback is called
>> with
>> the selected state.
>
>   One would first execute prepare then call select and enter .
>   So in the newer proposed code, there is no prepare routine. One would
>   just execute select() and then enter() (Prepare functionality is part of
> the
>   enter routine itself) Is it not possible to cancel the timer,
>   calculate the execute nohz_get_sleep in enter routine again,
>   then select the idle state depending on the time . Automatically promote
> or demote
>   idle state based on the latest value returned in the driver ?
>
Cancelling the timer and calculating the sleep length again in the enter
callback is possible; but what does not make sense is calling the select
routine again ; definitely the select routine of the governor needs to be
called only once.  And actually, the sleep length is calculated in the
function tick_nohz_stop_sched_tick.( so shld the prepare callback be moved
before that in cpu_idle ??)

I am looking for a nice way to cancel and restart the high resolution
timers in the idle code; even if that means rearranging the cpu_idle code.

Another way i was looking to solve this issue was add deferrable feature
to HR timers; if someone has thoughts on that please chime in.

thanks,
amar




>> So cancelling the hrtimer that would affect the residency value
>> calculated
>> in the menu governor, in the enter callback is not possible. The timer
>> needs to be cancelled before the select call is made.
>>
>> thanks,
>> amar
>>
>>
>>
>>> On 07/06/2011 04:23 PM, asinghal@xxxxxxxxxxxxxx wrote:
>>>> We plan to use high resolution timers in one of our modules, with the
>>>> requirement that we cancel these timers when the cpu goes idle and
>>>> restart
>>>> them when the cpu comes out of idle.
>>>>
>>>> We are cancelling the timers in cpuidle prepare callback. The problem
>>>> is
>>>> that if the need_resched() call in drivers/cpuidle/cpuidle.c returns
>>>> true,
>>>> how do we restart the timer? If the call returns false, we can restart
>>>> the
>>>> timer in the cpuidle enter callback.
>>>
>>> Hi Amar,
>>>
>>> I think you should not use cpuidle prepare callback at all. It may be
>>> removed soon (see https://lkml.org/lkml/2011/6/6/261) and I think
>>> there are better ways to achieve what you are trying to do.
>>>
>>> I think everything should go into the enter routines (the idle routines
>>> provided by the driver). That way you would not have to worry about
>>> need_resched() in cpuidle.c. Also it would be a cleaner implementation
>>> as you wouldn't touch generic cpuidle code.
>>>
>>>>
>>>> The solution to the problem that we have in mind is adding an
>>>> unprepare
>>>> callback to the cpuidle_device struct, and calling it if
>>>> needs_resched()
>>>> returns true. Another option is to implement deferred timers for
>>>> hrtimers.
>>>> Which of the two options is the better solution, or is there another
>>>> feasible alternative?
>>>
>>> As i said, everything should go inside enter routine and
>>> you wouldn't have to use/implement prepare/unprepare callbacks.
>>>
>>> Thanks
>>> -Trinabh
>>>
>>
>>
>> _______________________________________________
>> linux-pm mailing list
>> linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
> Regards,
> Deepthi
>


_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux