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

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(-)

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

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.

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?

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

quoted

Check pm qos cpu latency requirements before preparing for pm-idle

activities.

quoted

Scheduling is prevented during those operations and interrupt thread

serving

quoted

latency in increased. Driver can set pm qos latency requirement to

zero to

quoted

indicate extreme tight latency needs.

NAK.  This breaks hotplug CPU support.

ok 

quoted

 	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.

On Mon, Aug 09, 2010 at 12:12:47PM +0200, samu.p.onkalo at nokia.com wrote:

quoted

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

quoted

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.