From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de,
rjw@rjwysocki.net, preeti@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] idle: Add more comments to the code
Date: Tue, 11 Feb 2014 22:52:18 +0100 [thread overview]
Message-ID: <52FA9B92.5000705@linaro.org> (raw)
In-Reply-To: <alpine.LFD.2.11.1402111245400.17677@knanqh.ubzr>
On 02/11/2014 06:51 PM, Nicolas Pitre wrote:
> On Tue, 11 Feb 2014, Daniel Lezcano wrote:
>
>> The idle main function is a complex and a critical function. Added more
>> comments to the code.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> Few questions below. In any case,:
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
Thanks for the review Nico !
Answer below.
>> ---
>> kernel/sched/idle.c | 37 +++++++++++++++++++++++++++++++++----
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
>> index 72b5926..36ff1a7 100644
>> --- a/kernel/sched/idle.c
>> +++ b/kernel/sched/idle.c
>> @@ -86,19 +86,34 @@ static int cpuidle_idle_call(void)
>> if (cpu_idle_force_poll || tick_check_broadcast_expired())
>> return cpu_idle_poll();
>>
>> + /*
>> + * Check if the idle task must rescheduled. If it is the case,
>
> s/must/must be/
>
>> + * exit the function after re-enabling the local irq and set
>> + * again the polling flag
>> + */
>> if (current_clr_polling_and_test()) {
>> local_irq_enable();
>> __current_set_polling();
>> return 0;
>> }
>>
>> + /*
>> + * During the idle period, stop measuring the disabled irqs
>> + * critical sections latencies
>> + */
>> stop_critical_timings();
>> +
>> + /*
>> + * Tell the RCU framework we are entering an idle section,
>> + * so no more rcu read side critical sections and one more
>> + * step to the grace period
>> + */
>> rcu_idle_enter();
>>
>> - /* Ask the governor for the next state, this call can fail for
>> - * different reasons: cpuidle is not enabled or an idle state
>> - * fulfilling the constraints was not found. In this case, we fall
>> - * back to the default idle function
>> + /*
>> + * Ask the governor to choose an idle state it thinks it is
>> + * convenient to go to. There is *always* a convenient idle
>> + * state but the call could fail if cpuidle is not enabled
>> */
>> next_state = cpuidle_select(drv, dev);
>> if (next_state < 0) {
>> @@ -106,6 +121,10 @@ static int cpuidle_idle_call(void)
>> goto out;
>> }
>>
>> + /*
>> + * The idle task must be scheduled, it is pointless to go to idle,
>> + * just update no idle residency and get out of this function
>> + */
>> if (need_resched()) {
>> dev->last_residency = 0;
>> /* give the governor an opportunity to reflect on the outcome */
>
> Is this if block really necessary? We already have need_resched() being
> monitored in the outer loop. Are cpuidle_select() or rcu_idle_enter()
> likely to spend a significant amount of time justifying a recheck here?
That's a question I have been always asking myself.
The cpuidle_select function could spend some time for:
1. reflecting the idle time for the statistics of the previous idle
period. This processing is post-poned when exiting an idle state via the
'need_update' field in the cpuidle structure. I guess, this is because
it can take a while and we want to exit asap to reduce the wakeup latency.
2. there are some processing to choose the idle state.
I don't know what is the rational here to use need_resched at this place
except to 'abort' an idle state arbitrarily after some experimentation
for better reactivity. I am wondering if the multiple need_resched() we
find in the call stack for some idle states makes really sense and
doesn't denote a lack of control of what is happening in the idle path
vs system activity or a lack of confidence in the idle duration prediction.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2014-02-11 21:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 15:11 [PATCH 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Daniel Lezcano
2014-02-11 15:11 ` [PATCH 2/5] cpuidle/idle: Move the cpuidle_idle_call function to idle.c Daniel Lezcano
2014-02-12 10:43 ` Preeti U Murthy
2014-02-12 12:35 ` Daniel Lezcano
2014-02-11 15:11 ` [PATCH 3/5] idle: Reorganize the idle loop Daniel Lezcano
2014-02-11 17:36 ` Nicolas Pitre
2014-02-12 11:00 ` Preeti U Murthy
2014-02-12 12:45 ` Daniel Lezcano
2014-02-11 15:11 ` [PATCH 4/5] idle: Move idle conditions in cpuidle_idle main function Daniel Lezcano
2014-02-11 15:11 ` [PATCH 5/5] idle: Add more comments to the code Daniel Lezcano
2014-02-11 17:51 ` Nicolas Pitre
2014-02-11 21:52 ` Daniel Lezcano [this message]
2014-02-11 17:27 ` [PATCH 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Nicolas Pitre
2014-02-12 10:38 ` Preeti U Murthy
2014-02-12 12:37 ` Daniel Lezcano
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=52FA9B92.5000705@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).