CCing linux-pm list.
On Wed, May 26, 2010 at 9:07 PM, uthappa <utha...@mistralsolutions.com> wrote: > > Hello Everyone, > > I am currently working with the linux 2.6.29-omap1 kernel. Right now I > am porting a legacy application code that puts the OMAP 5912 host to > sleep. The host wakes up after 4 secs via an RTC interrupt which is > configured to be the wake-up source. Everything seems to be fine running > in a loop. The system wakes up and goes back to sleep in 4 seconds every > time. But I am observing a behavior that I am unable to explain. The > legacy application thread that puts the system to sleep is originally an > RT thread with the scheduling policy (SCHED_FIFO) and priority 5. The > thread runs in a loop. The following bash script mimics the behavior of > this thread exactly (however you will probably need some wake up source > like an RTC interrupt to try it on your side): > > ## Script start ############################# > > #!/bin/bash > > NAME_OF_THE_SCRIPT=`basename $0` > > SELF_PID=`pidof $NAME_OF_THE_SCRIPT` > /usr/bin/chrt -f -p 5 $SELF_PID > > sleep 1 > > while (true) > do > echo mem > /sys/power/state > usleep 30000 > done > > ## Script end ############################### > > With this thread running, I see the following messages looping > repeatedly on the target console screen: > > ## Console o/p start ############################# > > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.92 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.90 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.92 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > > ## Console o/p end ############################### > > You can observe from the above messages that the elapsed time in > "Freezing" the user processes is in the order of around 0.9 seconds. > Also, (although not evident here) when the message "Restarting > tasks ..." appears it takes around a second for the "done." message to > follow. > > Now comes the fun part. When I do not fiddle around with the scheduling > policy and priority of the legacy RT thread and just let it be a normal > user space thread (SCHED_OTHER with priority 20, nice 0) (You can > achieve this in the script that I shared with you all by simply > commenting out the command that says "/usr/bin/chrt -f -p 5 $SELF_PID"). > Then there is almost no delay at all during "Freezing" and > "Restarting" (I should probably call this "Thawing") the user space > tasks. That is, I now have the following console o/p: > > ## Console o/p start ############################# > > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > PM: OMAP16212316 is trying to enter deep sleep... > PM: OMAP16212316 is re-starting from deep sleep... > Restarting tasks ... RTC IRQ cleared > done. > > ## Console o/p end ############################### > > As you can see from the above log that the time elapsed during freeze > is now reported as 0.00 seconds. And I observed here that there is no > time delay between printing "Restarting tasks ..." and "done.". > > I am having a tough time searching for an explanation to this behavior. > And I hoping that some of you might have already experienced this > behavior or knows what is happening and can explain this to me. > > Many thanks in advance. > > Best regards, > Uthappa > > > > Please do not print this email unless it is absolutely necessary. Spread > environmental awareness. > > -------------------------------------------------------DISCLAIMER------------------------------------------------------ > The information transmitted herewith is confidential and proprietary > information intended only for use by the individual or entity to which it is > addressed. If the reader of this message is not the intended recipient, you > are hereby notified that any review, retransmission, dissemination, > distribution, copying or other use of, or taking of any action in reliance > upon this information is strictly prohibited. If you have received this > communication in error, please contact the sender and delete the material > from your computer. > --------------------------------------------------------------------------------------------------------------------------- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
