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

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