From: asinghal@codeaurora.org
To: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Cc: linux-pm@lists.linux-foundation.org, asinghal@codeaurora.org,
johlstei@codeaurora.org
Subject: Re: [RFC] Unprepare callback for cpuidle_device
Date: Mon, 11 Jul 2011 10:26:56 -0700 (PDT) [thread overview]
Message-ID: <473338c2d56302337f83871ce1c201e4.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <4E170010.2000403@linux.vnet.ibm.com>
hello Deepthi,
please see my replies inline:
> Hi Amar,
>
> On Friday 08 July 2011 01:22 AM, asinghal@codeaurora.org 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@codeaurora.org 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@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
> Regards,
> Deepthi
>
next prev parent reply other threads:[~2011-07-11 17:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-06 20:23 [RFC] Unprepare callback for cpuidle_device asinghal
2011-07-07 6:25 ` Trinabh Gupta
2011-07-07 19:52 ` asinghal
2011-07-08 13:03 ` Deepthi Dharwar
2011-07-11 17:26 ` asinghal [this message]
2011-07-11 19:08 ` Vaidyanathan Srinivasan
2011-07-11 21:45 ` asinghal
2011-07-12 18:32 ` Vaidyanathan Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=473338c2d56302337f83871ce1c201e4.squirrel@www.codeaurora.org \
--to=asinghal@codeaurora.org \
--cc=deepthi@linux.vnet.ibm.com \
--cc=johlstei@codeaurora.org \
--cc=linux-pm@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox