[PATCH 0/1] Skip idle loop in case of extreme pm qos latency

[PATCH 0/1] Skip idle loop in case of extreme pm qos latency

[Samu Onkalo]

Scheduling is prevented most of the time in idle loop. This causes hundreds of
microseconds delays to interrupt thread scheduling even in case of immediate
return from pm_idle. Driver can set pm-qos-requirement to 0 to indicate that
even this level of latency is not tolerated. In such case idle loop just
calls scheduler to get faster response. When CPU is idle, this delay hits all
the time. On a loaded system, delays in interrupt serving are more random and
can be better tolerated by the sensitite HW driver.

Samu Onkalo (1):
  arm: kernel: idle loop pm constraints

 arch/arm/kernel/process.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

[PATCH 1/1] arm: kernel: idle loop pm constraints

[Samu Onkalo]

Check pm qos cpu latency requirements before preparing for pm-idle activities.
Scheduling is prevented during those operations and interrupt thread serving
latency in increased. Driver can set pm qos latency requirement to zero to
indicate extreme tight latency needs.

Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com>
---
 arch/arm/kernel/process.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 401e38b..3645947 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -29,6 +29,7 @@
 #include <linux/utsname.h>
 #include <linux/uaccess.h>
 #include <linux/random.h>
+#include <linux/pm_qos_params.h>
 
 #include <asm/cacheflush.h>
 #include <asm/leds.h>
@@ -162,6 +163,12 @@ void cpu_idle(void)
 
 	/* endless idle loop with no priority at all */
 	while (1) {
+		if (pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY) == 0) {
+			preempt_enable_no_resched();
+			schedule();
+			preempt_disable();
+			continue;
+		}
 		tick_nohz_stop_sched_tick(1);
 		leds_event(led_idle_start);
 		while (!need_resched()) {
-- 
1.6.3.3

[PATCH 1/1] arm: kernel: idle loop pm constraints

[Russell King - ARM Linux]

On Fri, Aug 06, 2010 at 12:17:41PM +0300, Samu Onkalo wrote:
> Check pm qos cpu latency requirements before preparing for pm-idle activities.
> Scheduling is prevented during those operations and interrupt thread serving
> latency in increased. Driver can set pm qos latency requirement to zero to
> indicate extreme tight latency needs.

NAK.  This breaks hotplug CPU support.

>  	while (1) {
> +		if (pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY) == 0) {
> +			preempt_enable_no_resched();
> +			schedule();
> +			preempt_disable();
> +			continue;
> +		}

It's pointless to repeatedly call schedule() if need_resched() is not set -
and the need_resched() check is extremely cheap.

In any case, the parts that you're cutting out are the calls to
leds_event() down to tick_nohz_restart_sched_tick().  Do you know
where the additional latency comes from?  Is it the code in the
pm_idle() hook?

[PATCH 1/1] arm: kernel: idle loop pm constraints

[samu.p.onkalo at nokia.com]

>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>Sent: 07 August, 2010 17:15
>To: Onkalo Samu.P (Nokia-MS/Tampere)
>Cc: linux-arm-kernel at lists.infradead.org
>Subject: Re: [PATCH 1/1] arm: kernel: idle loop pm constraints
>
>On Fri, Aug 06, 2010 at 12:17:41PM +0300, Samu Onkalo wrote:
>> Check pm qos cpu latency requirements before preparing for pm-idle
>activities.
>> Scheduling is prevented during those operations and interrupt thread
>serving
>> latency in increased. Driver can set pm qos latency requirement to
>zero to
>> indicate extreme tight latency needs.
>
>NAK.  This breaks hotplug CPU support.

ok 

>
>>  	while (1) {
>> +		if (pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY) == 0) {
>> +			preempt_enable_no_resched();
>> +			schedule();
>> +			preempt_disable();
>> +			continue;
>> +		}
>
>It's pointless to repeatedly call schedule() if need_resched() is not
>set -
>and the need_resched() check is extremely cheap.

True. But point is that we can't allow cpu to go to idle or even prepare for idle.
However it is little bit better to run locally small loop when there is no need 
to schedule instead of continuous scheduling for nothing.

>
>In any case, the parts that you're cutting out are the calls to
>leds_event() down to tick_nohz_restart_sched_tick().  Do you know
>where the additional latency comes from?  Is it the code in the
>pm_idle() hook?

pm_idle is not the problem. Neither the leds_events. tick*() functions
seems to take 0 - 120 us each. In worst case over 200 us together.

If the interrupt arrives when tick_nohz_stop_sched_tick() is just called, irqs are disabled.
Rescheduling needs are noticed in the worst case after the 120 us. It may take about the same
time when going out. pm_idle is not called in this case.

Does this make sense at all to modify idle loop to get rid of this delay?
Of course only when pm latency requirements are set to 0.

[PATCH 1/1] arm: kernel: idle loop pm constraints

[Russell King - ARM Linux]

On Mon, Aug 09, 2010 at 12:12:47PM +0200, samu.p.onkalo at nokia.com wrote:
> >-----Original Message-----
> >From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> >Sent: 07 August, 2010 17:15
> >To: Onkalo Samu.P (Nokia-MS/Tampere)
> >Cc: linux-arm-kernel at lists.infradead.org
> >Subject: Re: [PATCH 1/1] arm: kernel: idle loop pm constraints
> >
> >It's pointless to repeatedly call schedule() if need_resched() is not
> >set -
> >and the need_resched() check is extremely cheap.
> 
> True. But point is that we can't allow cpu to go to idle or even prepare
> for idle.  However it is little bit better to run locally small loop when
> there is no need to schedule instead of continuous scheduling for nothing.

I don't buy these kinds of arguments - especially when they end up
breaking stuff.

> >In any case, the parts that you're cutting out are the calls to
> >leds_event() down to tick_nohz_restart_sched_tick().  Do you know
> >where the additional latency comes from?  Is it the code in the
> >pm_idle() hook?
> 
> pm_idle is not the problem. Neither the leds_events. tick*() functions
> seems to take 0 - 120 us each. In worst case over 200 us together.
> 
> If the interrupt arrives when tick_nohz_stop_sched_tick() is just called,
> irqs are disabled.  Rescheduling needs are noticed in the worst case after
> the 120 us. It may take about the same time when going out. pm_idle is not
> called in this case.

120us - 200us does seem rather excessive.  Maybe this should be reported to
the time subsystem maintainers.