Re: Delay in performing "suspend-to-ram" issued via RT thread (SCHED_FIFO)
CCing linux-pm list. On Wed, May 26, 2010 at 9:07 PM, uthappa 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 3 > 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
Delay in performing "suspend-to-ram" issued via RT thread (SCHED_FIFO)
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 3 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.
