All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
To: asinghal@codeaurora.org
Cc: linux-pm@lists.linux-foundation.org, johlstei@codeaurora.org
Subject: Re: [RFC] Unprepare callback for cpuidle_device
Date: Fri, 08 Jul 2011 18:33:12 +0530	[thread overview]
Message-ID: <4E170010.2000403@linux.vnet.ibm.com> (raw)
In-Reply-To: <82b596dce7b84db206d3afb6da564fb9.squirrel@www.codeaurora.org>

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 ?
 
> 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

  reply	other threads:[~2011-07-08 13:03 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 [this message]
2011-07-11 17:26       ` asinghal
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=4E170010.2000403@linux.vnet.ibm.com \
    --to=deepthi@linux.vnet.ibm.com \
    --cc=asinghal@codeaurora.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.