cpuidle and NO_HZ

cpuidle and NO_HZ

[Premi, Sanjeev]

Hi all,
 
While trying to use NFS hosted filesystem, I have made a strange observation. Have verified it on multiple OMAP3EVM boards.

With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print "Freeing init memory: 152K" in the log below; the boot sequence almost stops for approx a minute before proceeding further.
 
   Sending DHCP requests .<6>eth0: link up, 100Mbps, full-duplex, lpa 0x01E1
   ., OK
   IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.9
   IP-Config: Complete:
     device=eth0, addr=192.168.1.9, mask=255.255.255.0, gw=192.168.1.9,
     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
   Looking up port of RPC 100003/2 on 192.168.1.2
   Looking up port of RPC 100005/1 on 192.168.1.2
   VFS: Mounted root (nfs filesystem).
   Freeing init memory: 152K
   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
   starting pid 442, tty '': '/etc/init.d/rcS'
 
Later, the system response is slow.
 
Toggling either of these CONFIG options seems to resolve the issue.
 
My initial suspicion was on the SMC911x driver, but during this 'wait' period ping requests to the EVM are successful.

Just wanted to check if anyone has seen this behavior.
(I am on Kevin's latest PM branch 998bd5675a1e...).

Best regards,
Sanjeev

Re: cpuidle and NO_HZ

[Sriram V]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

Sanjeev,

On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev <premi@ti.com> wrote:
> Hi all,
>
> While trying to use NFS hosted filesystem, I have made a strange observation. Have verified it on multiple OMAP3EVM boards.
>
> With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print "Freeing init memory: 152K" in the log below; the boot sequence almost stops for approx a minute before proceeding further.
>
>   Sending DHCP requests .<6>eth0: link up, 100Mbps, full-duplex, lpa 0x01E1
>   ., OK
>   IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.9
>   IP-Config: Complete:
>     device=eth0, addr=192.168.1.9, mask=255.255.255.0, gw=192.168.1.9,
>     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
>     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
>   Looking up port of RPC 100003/2 on 192.168.1.2
>   Looking up port of RPC 100005/1 on 192.168.1.2
>   VFS: Mounted root (nfs filesystem).
>   Freeing init memory: 152K
>   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
>   starting pid 442, tty '': '/etc/init.d/rcS'
>

This seems to be a wakeup issue. SMC gpio irq needs to be enabled as a
wakeup source.
I notice that sometimes even after enabling it as a wakeup source
network interface has trouble. either it is too slow or it just hangs
during nfs mount or takes a long time to mount. this issue could be
somewhere else

I also notice that the whenever network interface hangs during nfs mount.
the nfs server would have exited.



Regards,
sriram







> Later, the system response is slow.
>
> Toggling either of these CONFIG options seems to resolve the issue.
>
> My initial suspicion was on the SMC911x driver, but during this 'wait' period ping requests to the EVM are successful.
>
> Just wanted to check if anyone has seen this behavior.
> (I am on Kevin's latest PM branch 998bd5675a1e...).
>
> Best regards,
> Sanjeev
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[-- Attachment #2: PM-OMAP3EVM-enable-smc-irq-gpio-as-a-wakeup-source.patch --]
[-- Type: text/x-patch, Size: 1072 bytes --]

From 0261fa7b7c006e649319ac02907abe35c6aa7a11 Mon Sep 17 00:00:00 2001
From: Sriram V <vsriram@mistralsolutions.com>
Date: Thu, 22 Jan 2009 22:27:29 +0530
Subject: [PATCH] PM: OMAP3EVM: enable smc irq gpio as a wakeup source

Signed-off-by: Sriram V <vsriram@mistralsolutions.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 6fbbe95..3eb8b60 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -19,6 +19,7 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/input.h>
+#include <linux/interrupt.h>
 
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
@@ -83,6 +84,10 @@ static inline void __init omap3evm_init_smc911x(void)
 	}
 
 	gpio_direction_input(OMAP3EVM_ETHR_GPIO_IRQ);
+
+#ifdef CONFIG_PM
+	enable_irq_wake(gpio_to_irq(OMAP3EVM_ETHR_GPIO_IRQ));
+#endif
 }
 
 static struct omap_uart_config omap3_evm_uart_config __initdata = {
-- 
1.6.1

RE: cpuidle and NO_HZ

[Premi, Sanjeev]

> -----Original Message-----
> From: Sriram V [mailto:vshrirama@gmail.com] 
> Sent: Thursday, January 22, 2009 10:37 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: cpuidle and NO_HZ
> 
> Sanjeev,
> 
> On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev <premi@ti.com> wrote:
> > Hi all,
> >
> > While trying to use NFS hosted filesystem, I have made a 
> strange observation. Have verified it on multiple OMAP3EVM boards.
> >
> > With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print 
> "Freeing init memory: 152K" in the log below; the boot 
> sequence almost stops for approx a minute before proceeding further.
> >
> >   Sending DHCP requests .<6>eth0: link up, 100Mbps, 
> full-duplex, lpa 0x01E1
> >   ., OK
> >   IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.9
> >   IP-Config: Complete:
> >     device=eth0, addr=192.168.1.9, mask=255.255.255.0, 
> gw=192.168.1.9,
> >     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
> >     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
> >   Looking up port of RPC 100003/2 on 192.168.1.2
> >   Looking up port of RPC 100005/1 on 192.168.1.2
> >   VFS: Mounted root (nfs filesystem).
> >   Freeing init memory: 152K
> >   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
> >   starting pid 442, tty '': '/etc/init.d/rcS'
> >
> 
> This seems to be a wakeup issue. SMC gpio irq needs to be 
> enabled as a wakeup source.
> I notice that sometimes even after enabling it as a wakeup 
> source network interface has trouble. either it is too slow 
> or it just hangs during nfs mount or takes a long time to 
> mount. this issue could be somewhere else
> 
> I also notice that the whenever network interface hangs 
> during nfs mount.
> the nfs server would have exited.

[sp]Thanks. I will try the patch.

I did believe it was a wakeup issue until I had not tried the ping.
All pings were successful; indicating that eth interface is still up.

The 'mount' succeeding after about a minute is confirms it as well.

Best regards,
Sanjeev
> 
> 
> 
> Regards,
> sriram
> 
> 
> 
> 
> 
> 
> 
> > Later, the system response is slow.
> >
> > Toggling either of these CONFIG options seems to resolve the issue.
> >
> > My initial suspicion was on the SMC911x driver, but during 
> this 'wait' period ping requests to the EVM are successful.
> >
> > Just wanted to check if anyone has seen this behavior.
> > (I am on Kevin's latest PM branch 998bd5675a1e...).
> >
> > Best regards,
> > Sanjeev
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> 

RE: cpuidle and NO_HZ

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, January 23, 2009 12:02 AM
> To: Sriram V
> Cc: linux-omap@vger.kernel.org
> Subject: RE: cpuidle and NO_HZ
> 
> > -----Original Message-----
> > From: Sriram V [mailto:vshrirama@gmail.com]
> > Sent: Thursday, January 22, 2009 10:37 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: cpuidle and NO_HZ
> > 
> > Sanjeev,
> > 
> > On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev 
> <premi@ti.com> wrote:
> > > Hi all,
> > >
> > > While trying to use NFS hosted filesystem, I have made a
> > strange observation. Have verified it on multiple OMAP3EVM boards.
> > >
> > > With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print
> > "Freeing init memory: 152K" in the log below; the boot 
> sequence almost 
> > stops for approx a minute before proceeding further.
> > >
> > >   Sending DHCP requests .<6>eth0: link up, 100Mbps,
> > full-duplex, lpa 0x01E1
> > >   ., OK
> > >   IP-Config: Got DHCP answer from 0.0.0.0, my address is 
> 192.168.1.9
> > >   IP-Config: Complete:
> > >     device=eth0, addr=192.168.1.9, mask=255.255.255.0,
> > gw=192.168.1.9,
> > >     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
> > >     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
> > >   Looking up port of RPC 100003/2 on 192.168.1.2
> > >   Looking up port of RPC 100005/1 on 192.168.1.2
> > >   VFS: Mounted root (nfs filesystem).
> > >   Freeing init memory: 152K
> > >   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
> > >   starting pid 442, tty '': '/etc/init.d/rcS'
> > >
> > 
> > This seems to be a wakeup issue. SMC gpio irq needs to be 
> enabled as a 
> > wakeup source.
> > I notice that sometimes even after enabling it as a wakeup source 
> > network interface has trouble. either it is too slow or it 
> just hangs 
> > during nfs mount or takes a long time to mount. this issue could be 
> > somewhere else
> > 
> > I also notice that the whenever network interface hangs during nfs 
> > mount.
> > the nfs server would have exited.
> 
> [sp]Thanks. I will try the patch.
> 
> I did believe it was a wakeup issue until I had not tried the ping.
> All pings were successful; indicating that eth interface is still up.
> 
> The 'mount' succeeding after about a minute is confirms it as well.
> 
> Best regards,
> Sanjeev
> > 

[sp] The patch did not help :( behavior is still the same

> > 
> > 
> > Regards,
> > sriram
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > Later, the system response is slow.
> > >
> > > Toggling either of these CONFIG options seems to resolve 
> the issue.
> > >
> > > My initial suspicion was on the SMC911x driver, but during
> > this 'wait' period ping requests to the EVM are successful.
> > >
> > > Just wanted to check if anyone has seen this behavior.
> > > (I am on Kevin's latest PM branch 998bd5675a1e...).
> > >
> > > Best regards,
> > > Sanjeev
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > linux-omap" 
> > > in the body of a message to majordomo@vger.kernel.org More
> > majordomo
> > > info at  http://vger.kernel.org/majordomo-info.html
> > >
> > --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
> 

Re: cpuidle and NO_HZ

[Sriram V]

Sanjeev,
I am not really sure what the problem could be.
By enabling smc irq as wakeup resulted in faster nfs mounts compared
to before. however this does not happen everytime.
On enabling smc debug i can see interrupts happening all while.
for me ping stops after a while.

Booting out a MMC card. I am unable to ping from the board. i see
rx overruns. However i can smc interrupts happening

For some reason this happens only when cpuidle is enabled.

Regards,
sriram






 But, i also see


Regards,
sriram



 as i said this could be something else.

Regards,
sriram




On Fri, Jan 23, 2009 at 6:58 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
>> Sent: Friday, January 23, 2009 12:02 AM
>> To: Sriram V
>> Cc: linux-omap@vger.kernel.org
>> Subject: RE: cpuidle and NO_HZ
>>
>> > -----Original Message-----
>> > From: Sriram V [mailto:vshrirama@gmail.com]
>> > Sent: Thursday, January 22, 2009 10:37 PM
>> > To: Premi, Sanjeev
>> > Cc: linux-omap@vger.kernel.org
>> > Subject: Re: cpuidle and NO_HZ
>> >
>> > Sanjeev,
>> >
>> > On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev
>> <premi@ti.com> wrote:
>> > > Hi all,
>> > >
>> > > While trying to use NFS hosted filesystem, I have made a
>> > strange observation. Have verified it on multiple OMAP3EVM boards.
>> > >
>> > > With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print
>> > "Freeing init memory: 152K" in the log below; the boot
>> sequence almost
>> > stops for approx a minute before proceeding further.
>> > >
>> > >   Sending DHCP requests .<6>eth0: link up, 100Mbps,
>> > full-duplex, lpa 0x01E1
>> > >   ., OK
>> > >   IP-Config: Got DHCP answer from 0.0.0.0, my address is
>> 192.168.1.9
>> > >   IP-Config: Complete:
>> > >     device=eth0, addr=192.168.1.9, mask=255.255.255.0,
>> > gw=192.168.1.9,
>> > >     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
>> > >     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
>> > >   Looking up port of RPC 100003/2 on 192.168.1.2
>> > >   Looking up port of RPC 100005/1 on 192.168.1.2
>> > >   VFS: Mounted root (nfs filesystem).
>> > >   Freeing init memory: 152K
>> > >   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
>> > >   starting pid 442, tty '': '/etc/init.d/rcS'
>> > >
>> >
>> > This seems to be a wakeup issue. SMC gpio irq needs to be
>> enabled as a
>> > wakeup source.
>> > I notice that sometimes even after enabling it as a wakeup source
>> > network interface has trouble. either it is too slow or it
>> just hangs
>> > during nfs mount or takes a long time to mount. this issue could be
>> > somewhere else
>> >
>> > I also notice that the whenever network interface hangs during nfs
>> > mount.
>> > the nfs server would have exited.
>>
>> [sp]Thanks. I will try the patch.
>>
>> I did believe it was a wakeup issue until I had not tried the ping.
>> All pings were successful; indicating that eth interface is still up.
>>
>> The 'mount' succeeding after about a minute is confirms it as well.
>>
>> Best regards,
>> Sanjeev
>> >
>
> [sp] The patch did not help :( behavior is still the same
>
>> >
>> >
>> > Regards,
>> > sriram
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > Later, the system response is slow.
>> > >
>> > > Toggling either of these CONFIG options seems to resolve
>> the issue.
>> > >
>> > > My initial suspicion was on the SMC911x driver, but during
>> > this 'wait' period ping requests to the EVM are successful.
>> > >
>> > > Just wanted to check if anyone has seen this behavior.
>> > > (I am on Kevin's latest PM branch 998bd5675a1e...).
>> > >
>> > > Best regards,
>> > > Sanjeev
>> > > --
>> > > To unsubscribe from this list: send the line "unsubscribe
>> > linux-omap"
>> > > in the body of a message to majordomo@vger.kernel.org More
>> > majordomo
>> > > info at  http://vger.kernel.org/majordomo-info.html
>> > >
>> > --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-omap" in the body of a message to
>> majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>
>>

Re: cpuidle and NO_HZ

[Kevin Hilman]

Sriram V <vshrirama@gmail.com> writes:

> Sanjeev,
> I am not really sure what the problem could be.
> By enabling smc irq as wakeup resulted in faster nfs mounts compared
> to before. however this does not happen everytime.
> On enabling smc debug i can see interrupts happening all while.
> for me ping stops after a while.
>
> Booting out a MMC card. I am unable to ping from the board. i see
> rx overruns. However i can smc interrupts happening
>
> For some reason this happens only when cpuidle is enabled.

Are you allowing the chip to hit OFF (by 'echo 1 >
/sys/power/enable_off_mode') or are you only hitting retention.

This is most likely a latency issue.  For starters, you could modify
the smc91x driver to register a latency requirement with the OMAP PM
layer.  This would prevent entering deeper C-states which may have
wakeup latencies that the smc91x cannot handle.

Alternatively, you you do some experiments to see exactly which
C-states are causing the problems.  You could modify cpuidle34xx.c and
set the 'valid' flag in the higher C-states to zero so that they
cannot be entered and see which C-states (if any) are working.

That being said, I'm not sure how this could be happening during boot,
since the UART clocks should be preventing retention or off
until you 'echo 1 > /sys/power/clocks_off_when_idle.'

Kevin

>
>
>
>
>
>
>  But, i also see
>
>
> Regards,
> sriram
>
>
>
>  as i said this could be something else.
>
> Regards,
> sriram
>
>
>
>
> On Fri, Jan 23, 2009 at 6:58 PM, Premi, Sanjeev <premi@ti.com> wrote:
>>> -----Original Message-----
>>> From: linux-omap-owner@vger.kernel.org
>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
>>> Sent: Friday, January 23, 2009 12:02 AM
>>> To: Sriram V
>>> Cc: linux-omap@vger.kernel.org
>>> Subject: RE: cpuidle and NO_HZ
>>>
>>> > -----Original Message-----
>>> > From: Sriram V [mailto:vshrirama@gmail.com]
>>> > Sent: Thursday, January 22, 2009 10:37 PM
>>> > To: Premi, Sanjeev
>>> > Cc: linux-omap@vger.kernel.org
>>> > Subject: Re: cpuidle and NO_HZ
>>> >
>>> > Sanjeev,
>>> >
>>> > On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev
>>> <premi@ti.com> wrote:
>>> > > Hi all,
>>> > >
>>> > > While trying to use NFS hosted filesystem, I have made a
>>> > strange observation. Have verified it on multiple OMAP3EVM boards.
>>> > >
>>> > > With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print
>>> > "Freeing init memory: 152K" in the log below; the boot
>>> sequence almost
>>> > stops for approx a minute before proceeding further.
>>> > >
>>> > >   Sending DHCP requests .<6>eth0: link up, 100Mbps,
>>> > full-duplex, lpa 0x01E1
>>> > >   ., OK
>>> > >   IP-Config: Got DHCP answer from 0.0.0.0, my address is
>>> 192.168.1.9
>>> > >   IP-Config: Complete:
>>> > >     device=eth0, addr=192.168.1.9, mask=255.255.255.0,
>>> > gw=192.168.1.9,
>>> > >     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
>>> > >     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
>>> > >   Looking up port of RPC 100003/2 on 192.168.1.2
>>> > >   Looking up port of RPC 100005/1 on 192.168.1.2
>>> > >   VFS: Mounted root (nfs filesystem).
>>> > >   Freeing init memory: 152K
>>> > >   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
>>> > >   starting pid 442, tty '': '/etc/init.d/rcS'
>>> > >
>>> >
>>> > This seems to be a wakeup issue. SMC gpio irq needs to be
>>> enabled as a
>>> > wakeup source.
>>> > I notice that sometimes even after enabling it as a wakeup source
>>> > network interface has trouble. either it is too slow or it
>>> just hangs
>>> > during nfs mount or takes a long time to mount. this issue could be
>>> > somewhere else
>>> >
>>> > I also notice that the whenever network interface hangs during nfs
>>> > mount.
>>> > the nfs server would have exited.
>>>
>>> [sp]Thanks. I will try the patch.
>>>
>>> I did believe it was a wakeup issue until I had not tried the ping.
>>> All pings were successful; indicating that eth interface is still up.
>>>
>>> The 'mount' succeeding after about a minute is confirms it as well.
>>>
>>> Best regards,
>>> Sanjeev
>>> >
>>
>> [sp] The patch did not help :( behavior is still the same
>>
>>> >
>>> >
>>> > Regards,
>>> > sriram
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > Later, the system response is slow.
>>> > >
>>> > > Toggling either of these CONFIG options seems to resolve
>>> the issue.
>>> > >
>>> > > My initial suspicion was on the SMC911x driver, but during
>>> > this 'wait' period ping requests to the EVM are successful.
>>> > >
>>> > > Just wanted to check if anyone has seen this behavior.
>>> > > (I am on Kevin's latest PM branch 998bd5675a1e...).
>>> > >
>>> > > Best regards,
>>> > > Sanjeev
>>> > > --
>>> > > To unsubscribe from this list: send the line "unsubscribe
>>> > linux-omap"
>>> > > in the body of a message to majordomo@vger.kernel.org More
>>> > majordomo
>>> > > info at  http://vger.kernel.org/majordomo-info.html
>>> > >
>>> > --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-omap" in the body of a message to
>>> majordomo@vger.kernel.org More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>>
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: cpuidle and NO_HZ <boot speedup>

[Woodruff, Richard]

> Alternatively, you you do some experiments to see exactly which
> C-states are causing the problems.  You could modify cpuidle34xx.c and
> set the 'valid' flag in the higher C-states to zero so that they
> cannot be entered and see which C-states (if any) are working.

I recently added the following hack which cut boot time in half and removed many early network issues.

I've not converted it to the latest kernel but how to do it is simple.

Basically it delays as long as possible CPUIdle init to remove its cost during a lot of boot.  Then it sets a constraint which is command line override-able to allow the application to boot.

We recommend doing this along with setting an OPP constraint so you're in overdrive during boot time.  Today we start off with performance governor to achieve this, then switch to on-demand for tracking later on.

During boot and initial applications startup you want these things.

Probably I'll update it to pmqos in a few weeks if I have time.  It has shown to be worth while in speeding up boot up.

diff -purN img/2.6_kernel/arch/arm/mach-omap2/pm_idle_34xx.c 2.6_kernel/arch/arm/mach-omap2/pm_idle_34xx.c
--- img/2.6_kernel/arch/arm/mach-omap2/pm_idle_34xx.c   2008-12-09 20:24:31.000000000 -0600
+++ 2.6_kernel/arch/arm/mach-omap2/pm_idle_34xx.c       2008-12-19 20:13:30.000000000 -0600
@@ -917,6 +918,24 @@ struct cpuidle_driver omap3_idle_driver
        .owner =        THIS_MODULE,
 };

+/* Gate long latency C states for 20 seconds to reduce boot time */
+static unsigned int __initdata boot_noidle_time = 20;
+
+/* Command line override to allow matching with application start time */
+static int __init boot_noidle_time_setup(char *str)
+{
+       get_option(&str, &boot_noidle_time);
+       return 1;
+}
+__setup("boot_noidle_time=", boot_noidle_time_setup);
+
+
+struct timer_list boot_timer;
+static void omap_boot_timer(unsigned long arg)
+{
+       remove_acceptable_latency("idle_delay");
+}
+
 int omap3_idle_init(void)
 {
        int i, count = 0;
@@ -963,6 +982,15 @@ int omap3_idle_init(void)
        /* Initialize UART inactivity time */
        awake_time_end = jiffies + msecs_to_jiffies(UART_TIME_OUT);

+       /* For boot speed restrict C-State to C0 until boot done */
+       init_timer(&boot_timer);
+       boot_timer.function = omap_boot_timer;
+       boot_timer.data = (unsigned long)NULL;
+       boot_timer.expires = boot_noidle_time * HZ + jiffies;
+       add_timer(&boot_timer);
+       set_acceptable_latency("idle_delay", 10);
+
        return 0;
 }
-__initcall(omap3_idle_init);
+/* Install omap3_idle idle last to speed up boot */
+late_initcall_sync(omap3_idle_init);
diff -purN img/2.6_kernel/kernel/latency.c 2.6_kernel/kernel/latency.c
--- img/2.6_kernel/kernel/latency.c     2008-10-17 14:10:28.000000000 -0500
+++ 2.6_kernel/kernel/latency.c 2008-12-18 19:44:22.000000000 -0600
@@ -269,11 +269,13 @@ EXPORT_SYMBOL_GPL(unregister_latency_not
 static __init int latency_init(void)
 {
        atomic_set(&current_max_latency, INFINITE_LATENCY);
+#ifndef CONFIG_OMAP3_PM
        /*
         * we don't want by default to have longer latencies than 2 ticks,
         * since that would cause lost ticks
         */
        set_acceptable_latency("kernel", 2*1000000/HZ);
+#endif
        return 0;
 }

RE: cpuidle and NO_HZ

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, January 23, 2009 11:02 PM
> To: Sriram V
> Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: Re: cpuidle and NO_HZ
> 
> Sriram V <vshrirama@gmail.com> writes:
> 
> > Sanjeev,
> > I am not really sure what the problem could be.
> > By enabling smc irq as wakeup resulted in faster nfs mounts 
> compared 
> > to before. however this does not happen everytime.
> > On enabling smc debug i can see interrupts happening all while.
> > for me ping stops after a while.
> >
> > Booting out a MMC card. I am unable to ping from the board. 
> i see rx 
> > overruns. However i can smc interrupts happening

[sp] Haven't tried booting from MMC so far

> >
> > For some reason this happens only when cpuidle is enabled.
> 

[sp] I notice it only when both cpuidle & dynamic tick are enabled.
BTW, what is the uboot version you are using?

> Are you allowing the chip to hit OFF (by 'echo 1 >
> /sys/power/enable_off_mode') or are you only hitting retention.
> 
> This is most likely a latency issue.  For starters, you could 
> modify the smc91x driver to register a latency requirement 
> with the OMAP PM layer.  This would prevent entering deeper 
> C-states which may have wakeup latencies that the smc91x 
> cannot handle.
> 

[sp] Once the kernel boots-up (thought very slow & late), powertop doesn't indicate any state transition from C0 despite enabling sleep_when_idle.

> Alternatively, you you do some experiments to see exactly 
> which C-states are causing the problems.  You could modify 
> cpuidle34xx.c and set the 'valid' flag in the higher C-states 
> to zero so that they cannot be entered and see which C-states 
> (if any) are working.
> 
> That being said, I'm not sure how this could be happening 
> during boot, since the UART clocks should be preventing 
> retention or off until you 'echo 1 > /sys/power/clocks_off_when_idle.'
> 
> Kevin
> 
> >
> >
> >
> >
> >
> >
> >  But, i also see
> >
> >
> > Regards,
> > sriram
> >
> >
> >
> >  as i said this could be something else.
> >
> > Regards,
> > sriram
> >
> >
> >
> >
> > On Fri, Jan 23, 2009 at 6:58 PM, Premi, Sanjeev 
> <premi@ti.com> wrote:
> >>> -----Original Message-----
> >>> From: linux-omap-owner@vger.kernel.org 
> >>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, 
> >>> Sanjeev
> >>> Sent: Friday, January 23, 2009 12:02 AM
> >>> To: Sriram V
> >>> Cc: linux-omap@vger.kernel.org
> >>> Subject: RE: cpuidle and NO_HZ
> >>>
> >>> > -----Original Message-----
> >>> > From: Sriram V [mailto:vshrirama@gmail.com]
> >>> > Sent: Thursday, January 22, 2009 10:37 PM
> >>> > To: Premi, Sanjeev
> >>> > Cc: linux-omap@vger.kernel.org
> >>> > Subject: Re: cpuidle and NO_HZ
> >>> >
> >>> > Sanjeev,
> >>> >
> >>> > On Thu, Jan 22, 2009 at 8:14 PM, Premi, Sanjeev
> >>> <premi@ti.com> wrote:
> >>> > > Hi all,
> >>> > >
> >>> > > While trying to use NFS hosted filesystem, I have made a
> >>> > strange observation. Have verified it on multiple 
> OMAP3EVM boards.
> >>> > >
> >>> > > With CONFIG_NO_HZ and CONFIG_CPU_IDLE, after the print
> >>> > "Freeing init memory: 152K" in the log below; the boot
> >>> sequence almost
> >>> > stops for approx a minute before proceeding further.
> >>> > >
> >>> > >   Sending DHCP requests .<6>eth0: link up, 100Mbps,
> >>> > full-duplex, lpa 0x01E1
> >>> > >   ., OK
> >>> > >   IP-Config: Got DHCP answer from 0.0.0.0, my address is
> >>> 192.168.1.9
> >>> > >   IP-Config: Complete:
> >>> > >     device=eth0, addr=192.168.1.9, mask=255.255.255.0,
> >>> > gw=192.168.1.9,
> >>> > >     host=192.168.1.9, domain=india.ti.com, nis-domain=(none),
> >>> > >     bootserver=0.0.0.0, rootserver=192.168.1.2, rootpath=
> >>> > >   Looking up port of RPC 100003/2 on 192.168.1.2
> >>> > >   Looking up port of RPC 100005/1 on 192.168.1.2
> >>> > >   VFS: Mounted root (nfs filesystem).
> >>> > >   Freeing init memory: 152K
> >>> > >   init started: BusyBox v1.11.1 (2008-08-06 21:12:30 IST)
> >>> > >   starting pid 442, tty '': '/etc/init.d/rcS'
> >>> > >
> >>> >
> >>> > This seems to be a wakeup issue. SMC gpio irq needs to be
> >>> enabled as a
> >>> > wakeup source.
> >>> > I notice that sometimes even after enabling it as a 
> wakeup source 
> >>> > network interface has trouble. either it is too slow or it
> >>> just hangs
> >>> > during nfs mount or takes a long time to mount. this 
> issue could 
> >>> > be somewhere else
> >>> >
> >>> > I also notice that the whenever network interface hangs 
> during nfs 
> >>> > mount.
> >>> > the nfs server would have exited.
> >>>
> >>> [sp]Thanks. I will try the patch.
> >>>
> >>> I did believe it was a wakeup issue until I had not tried 
> the ping.
> >>> All pings were successful; indicating that eth interface 
> is still up.
> >>>
> >>> The 'mount' succeeding after about a minute is confirms 
> it as well.
> >>>
> >>> Best regards,
> >>> Sanjeev
> >>> >
> >>
> >> [sp] The patch did not help :( behavior is still the same
> >>
> >>> >
> >>> >
> >>> > Regards,
> >>> > sriram
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > > Later, the system response is slow.
> >>> > >
> >>> > > Toggling either of these CONFIG options seems to resolve
> >>> the issue.
> >>> > >
> >>> > > My initial suspicion was on the SMC911x driver, but during
> >>> > this 'wait' period ping requests to the EVM are successful.
> >>> > >
> >>> > > Just wanted to check if anyone has seen this behavior.
> >>> > > (I am on Kevin's latest PM branch 998bd5675a1e...).
> >>> > >
> >>> > > Best regards,
> >>> > > Sanjeev
> >>> > > --
> >>> > > To unsubscribe from this list: send the line "unsubscribe
> >>> > linux-omap"
> >>> > > in the body of a message to majordomo@vger.kernel.org More
> >>> > majordomo
> >>> > > info at  http://vger.kernel.org/majordomo-info.html
> >>> > >
> >>> > --
> >>> To unsubscribe from this list: send the line "unsubscribe 
> >>> linux-omap" in the body of a message to majordomo@vger.kernel.org 
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >>>
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
>