Linux kernel suspend status
The Linux kernel supports several types of sleep states, and the power-saving function is achieved by setting different modules into low-power mode. There are currently four modes: suspend to Idle, power-on standby (standby), suspend to RAM (STR) and sudpend to disk (Hibernate), respectively, corresponding to the ACPI state S0, S1, S3 and S4.
Suspend to Idle is completely software-related and tries to keep the CPU in a deep idle state.
power-on standby sets the device into low-power mode and shuts down all non-boot CPUs.
Suspend to RAM goes a step further, shutting down all CPUs and setting ram into self-refresh mode.
Suspend to disk is the most power-saving mode, by shutting down the device as much as possible, including RAM. Ram data is written to disk and read back to ram at resume.
The following uses STR to indicate that suspend to Ram,sti represents suspend to Idle.
For more information, please refer to: http://www.linaro.org/blog/suspend-to-idle/
STR and STI differences
How to get Hikey into Str/sti and wake up?
You can wake up by configuring a gpio as the wake-up source, or by using RTC as the wake-up source for a certain time delay.
Check to see if there is a/sys/class/rtc/rtc0/wakealarm, and you need to open config_rtc_drv_pl031 if it does not exist.
Writes the Wakealarm parameter, indicating the number of seconds after which the resume wakes up, exiting suspend.
Writing mem into state is the system entering the suspend process.
ADB root && adb remount
ADB shell "echo +10 >/sys/class/rtc/rtc0/wakealarm && echo mem >/sys/power/state" |
Here is the log for Hikey:
| [1667.963901] pm:suspend entry 1970-01-01 00:29:07.693811637 UTC
[1667.969940] pm:syncing filesystems ... done.
[1667.982169] Freezing user space processes ...
[1667.988694] DWC2 f72c0000.usb:dwc2_hsotg_ep_stop_xfr:timeout doepctl. Epdisable
[1667.996398] DWC2 F72c0000.usb:GINNakEff triggered
[1668.005715] (elapsed 0.019 seconds) done.
[1668.009858] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[1668.019035] Suspending Console (s) (use No_console_suspend to debug)
[1668.053839] Pm:suspend of devices complete after 27.658 msecs
[1668.056277] pm:late suspend of devices complete after 2.415 msecs
[1668.057494] PM:NOIRQ suspend of devices complete after 1.207 msecs
[1668.057500] disabling Non-boot CPUs ...
[1668.058575] cpu7:update Max cpu_capacity 1024
[1668.074889] Cpu1:shutdown
[1668.090447] psci:retrying again to check for CPU kill
[1668.090452] psci:cpu1 killed.
[1668.110472] cpu0:update Max cpu_capacity 1024
[1668.122990] Cpu2:shutdown
[1668.138453] psci:retrying again to check for CPU kill
[1668.138459] Psci:cpu2 killed.
[1668.158467] cpu7:update Max cpu_capacity 1024
[1668.170909] Cpu3:shutdown
[1668.186453] psci:retrying again to check for CPU kill
[1668.186458] Psci:cpu3 killed.
[1668.202446] cpu7:update Max cpu_capacity 1024
[1668.214925] Cpu4:shutdown
[1668.230450] psci:retrying again to check for CPU kill
[1668.230456] Psci:cpu4 killed.
[1668.246443] cpu7:update Max cpu_capacity 1024
[1668.254736] Cpu5:shutdown
[1668.270454] psci:retrying again to check for CPU kill
[1668.270459] Psci:cpu5 killed.
[1668.286440] cpu7:update Max cpu_capacity 1024
[1668.298735] Cpu6:shutdown
[1668.314450] psci:retrying again to check for CPU kill
[1668.314456] Psci:cpu6 killed.
[1668.346706] Cpu7:shutdown
[1668.362444] psci:retrying again to check for CPU kill
[1668.362451] Psci:cpu7 killed.
<<<<<<wakealarm
[1668.375740] Enabling Non-boot CPUs ...
[1668.395368] Detected vipt i-cache on CPU1
[1668.395428] Cpu1:update cpu_capacity 1024
[1668.395433] cpu1:booted secondary processor [410fd033]
[1668.395922] cache:parent cpu1 should not being sleeping
[1668.396127] CPU1 is up
[1668.398426] cpu0:update Max cpu_capacity 1024
[1668.415481] Detected vipt i-cache on CPU2
[1668.415525] Cpu2:update cpu_capacity 1024
[1668.415528] cpu2:booted secondary processor [410fd033]
[1668.416037] cache:parent cpu2 should not being sleeping
[1668.416231] CPU2 is up
[1668.418426] cpu0:update Max cpu_capacity 1024
[1668.435687] Detected vipt i-cache on CPU3
[1668.435731] Cpu3:update cpu_capacity 1024
[1668.435734] cpu3:booted secondary processor [410fd033]
[1668.436358] cache:parent cpu3 should not being sleeping
[1668.436561] CPU3 is up
[1668.438431] cpu0:update Max cpu_capacity 1024
[1668.456000] Detected vipt i-cache on CPU4
[1668.456072] Cpu4:update cpu_capacity 1024
[1668.456075] cpu4:booted secondary processor [410fd033]
[1668.456935] cache:parent cpu4 should not being sleeping
[1668.457133] CPU4 is up
[1668.458436] cpu0:update Max cpu_capacity 1024
[1668.476115] Detected vipt i-cache on CPU5
[1668.476148] Cpu5:update cpu_capacity 1024
[1668.476152] cpu5:booted secondary processor [410fd033]
[1668.477156] cache:parent cpu5 should not being sleeping
[1668.477352] CPU5 is up
[1668.478437] cpu0:update Max cpu_capacity 1024
[1668.496340] Detected vipt i-cache on CPU6
[1668.496373] Cpu6:update cpu_capacity 1024
[1668.496377] cpu6:booted secondary processor [410fd033]
[1668.497588] cache:parent cpu6 should not being sleeping
[1668.497792] CPU6 is up
[1668.498444] cpu0:update Max cpu_capacity 1024
[1668.516578] Detected vipt i-cache on CPU7
[1668.516611] Cpu7:update cpu_capacity 1024
[1668.516615] cpu7:booted secondary processor [410fd033]
[1668.518090] cache:parent cpu7 should not being sleeping
[1668.518290] CPU7 is up
[1668.518397] cpu7:update Max cpu_capacity 1024
[1668.519227] PM:NOIRQ resume of devices complete after 0.745 msecs
[1668.520384] pm:early resume of devices complete after 0.862 msecs
[1668.542885] mmc_host Mmc0:bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
[1668.618289] mmc_host Mmc0:bus speed (slot 0) = 51756522Hz (slot req 52000000Hz, actual 51756522HZ div = 0)
[1668.714903] mmc_host Mmc2:bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
[1668.764121] mmc_host Mmc2:bus speed (slot 0) = 24800000Hz (slot req 25000000Hz, actual 24800000HZ div = 0)
[1668.765001] Pm:resume of devices complete after 244.605 msecs
[1669.132522] Restarting tasks ...
[1669.136471] ueventd:fixup/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq 1000 1000 664
[1669.137761] done.
[1669.148351] ueventd:fixup/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq 1000 1000 664
[1669.157242] Pm:suspend exit 1970-01-01 00:29:17.630614166 UTC
[1669.172643] ueventd:fixup/sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq 1000 1000 664
[1669.181547] ueventd:fixup/sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq 1000 1000 664
[1669.205449] ueventd:fixup/sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq 1000 1000 664
[1669.214348] ueventd:fixup/sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq 1000 1000 664
[1669.238311] ueventd:fixup/sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq 1000 1000 664
[1669.247221] ueventd:fixup/sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 1000 1000 664
[1669.271362] ueventd:fixup/sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq 1000 1000 664
[1669.280255] ueventd:fixup/sys/devices/system/cpu/cpu5/cpufreq/scaling_min_freq 1000 1000 664
[1669.304141] ueventd:fixup/sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq 1000 1000 664
[1669.313161] ueventd:fixup/sys/devices/system/cpu/cpu6/cpufreq/scaling_min_freq 1000 1000 664
[1669.337039] ueventd:fixup/sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq 1000 1000 664
[1669.345936] ueventd:fixup/sys/devices/system/cpu/cpu7/cpufreq/scaling_min_freq 1000 1000 664 |
Latency analysis means of suspend/resume analyze_suspend.py v3.0
In kernel's scripts, this tool can help the kernel and OS developers optimize suspend/resume time.
After opening a series of kernel options, the tool can perform suspend operations and then crawl DMESG and ftrace data until the resume is finished.
This data displays each device according to the timeline, and displays a detailed view of the invocation relationship for the device or subsystem that occupies the most suspend/resume time.
After executing the tool, a subdirectory is generated based on the time, which contains: HTML, DMESG, and the original Ftrace file.
Here's a quick look at the tool options:
| Options:
[General]
-H Print This help text
-V Print the current tool version
-verbose Print extra information during execution and analysis
-status Test to see if the system was enabled to run this tool
-modes List available suspend modes shows the currently supported suspend modes
-m mode mode to initiate for suspend [' Freeze ', ' mem ', ' Disk '] (DEFAULT:MEM) set into what mode suspend
-rtcwake t use Rtcwake to Autoresume after <t> seconds (default:disabled) wake up using RTC, parameter is time interval
[Advanced]
-F Use Ftrace to create device callgraphs (default:disabled) build call graph based on Ftrace
-filter "D1 D2 ..." Filter out all but this list of dev names
-x2 Run-Suspend/resumes back-to-back (default:disabled)
-x2delay T Minimum millisecond delay <t> between the test runs (default:0 ms)
-postres T time after resume completion to wait for Post-resume events (default:0 S)
-multi n d Execute <n> consecutive Tests at <d> seconds intervals. The outputs would
Be created in a new subdirectory with a summary page.
[Utilities]
-FPDT Print out the contents of the ACPI Firmware performance Data Table
-usbtopo Print out the current USB topology with power info
-usbauto Enable autosuspend for all connected USB devices
[Android Testing]
-ADB binary use the given ADB binary to run of the test on an Android device. The parameters need to give the ADB path, and the tool will test the Android device and pull the results out. It is important to note that prior to this, make sure that ADB has root privileges.
The device should already is connected and with root access.
Commands'll be executed on the device using "adb shell"
[Re-analyze data from previous runs] re-analyzed for previous test data
-ftrace ftracefile Create HTML output using ftrace input
-DMESG dmesgfile Create HTML output using DMESG (not needed for kernel >= 3.15)
-summary Directory Create A summary of all test in this dir |
Once you know how to use the tool, you can test it.
Android
1.Android on the test Str,suspend/resume total 10 times, each interval of 5 seconds. -F is not implemented on the Android platform.
| ./analyze_suspend.py-adb/usr/bin/adb-rtcwake 5-multi 5-m Mem |
2.Android on the test Sti,suspend/resume total 10 times, each interval of 5 seconds.
| ./analyze_suspend.py-adb/usr/bin/adb-rtcwake 5-multi 5-m Freeze |
Existing problem: analyze_suspend.py does not support Android Rtcwakeup. Fix already in the following:
https://github.com/arnoldlu/common-use/blob/master/tools/analyze_suspend.py
Here is the test results on the Hikey, you can see that two data are not stable enough. Mem's suspend and resume averages are relatively high.
Ubuntu
This tool shows more powerful features on Ubuntu.
After supporting the CallGraph function, it is more clear to analyze the time taken by each device or subsystem suspend/resume.
sudo./analyze_suspend.py-rtcwake 5-multi 5-f-M mem
sudo./analyze_suspend.py-rtcwake 5-multi 5-f-M freeze |
After comparing the two different suspend modes, it is found that freeze takes less time than mem. This is also expected, but there is no power consumption data? _.
But the time data of mem mode is not stable enough ...? _?
The following is an analysis of how this tool is based.
Overall tool Interface Analysis
The top shows kernel Suspend time and kernel Resume time, which can be viewed in general for fallback or progress.
And here are some zoom buttons.
Then is based on the timeline chart, compared to the color, you can clearly see suspend prepare, suspend, suspend late, suspend IRQ, suspend machine, resume machine, resume The distribution of IRQ, resume early, resume, and resume complete.
The bottom is the detailed function call graph for each module, subsystem, and the start time and consumption time.
Detailed analysis of subsystems and modules
With a module selected, the detailed module will be displayed at the bottom of the suspend/resume time spent at each stage, as well as the function call graph.
Zoom View Details
Zoom in to zoom in, Zoomout Zoom out, zoom 1:1 restores the original size.
By zooming in on the timeline chart, you can see how much time is consumed by smaller modules. From macro to module, then to function consumption time, gradually refinement, is conducive to analysis.
If you find that a function occupies a large amount of time, you can expand it. Know that the discovery eventually takes up a larger function and finds out where the problem lies.
Reference documents
Power Management Support in Hikey (Suspend-resume): http://www.96boards.org/forums/topic/ power-management-support-in-hikey-suspend-resume/#gsc. tab=0
Suspend to idle:http://www.linaro.org/blog/suspend-to-idle/
Suspend and Resume:https://01.org/zh/suspendresume
Suspendandresume Github:https://github.com/arnoldlu/suspendresume
Linux Power Management (6) _generic pm Suspend function: http://www.wowotech.net/pm_subsystem/suspend_and_resume.html
Suspend to RAM and Suspend to idle analysis, and performance comparisons on Hikey
