Suspend to RAM和Suspend to Idle分析，以及在HiKey上性能对比

Linux内核suspend状态

Linux内核支持多种类型的睡眠状态，通过设置不同的模块进入低功耗模式来达到省电功能。目前存在四种模式：suspend to idle、power-on standby（Standby）、suspend to ram（STR）和sudpend to disk（Hibernate），分别对应ACPI状态的S0、S1、S3和S4。

Suspend to idle完全是软件相关的并且尽量将CPU维持在深度idle状态。

Power-on standby设置设备进入低功耗模式并且关闭所有non-boot CPU。

Suspend to ram就更进一步，关闭所有CPU并且设置RAM进入自刷新模式。（在HiKey的实际测试中，boot CPU是没有关闭的！实际上这里也没有standby，mem和standby基本上没有区别。）

Suspend to disk是最省功耗的模式，通过尽可能的关闭设备，包括RAM。RAM的数据会被写入磁盘中，在resume的时候读回到RAM。

下面用STR表示Suspend to RAM，STI表示Suspend to Idle。

详情请参考：http://www.linaro.org/blog/suspend-to-idle/

STR 和STI区别

写入/sys/power/state不同字符串，可以让系统进入不同睡眠状态。

#define PM_SUSPEND_ON        ((__force suspend_state_t) 0)  正常工作状态
#define PM_SUSPEND_FREEZE    ((__force suspend_state_t) 1) 对应suspend to idle
#define PM_SUSPEND_STANDBY    ((__force suspend_state_t) 2)  对应power-on standby
#define PM_SUSPEND_MEM        ((__force suspend_state_t) 3)  对应suspend to idle
#define PM_SUSPEND_MIN        PM_SUSPEND_FREEZE
#define PM_SUSPEND_MAX        ((__force suspend_state_t) 4)  对应suspend to disk，即hibernate

针对state sysfs节点的写入，最终会进入到state_store这个函数，将字符串转换成上表中不同状态。

state_store(kernel/power/main.c)
    -->pm_suspend (kernel/power/suspend.c) 处理除freeze、standby、mem三种类型suspend
        -->enter_state  在进入睡眠之前，做一些准备工作
            -->suspend_devices_and_enter 
                -->suspend_enter  这里才是freeze与standby/mem区别所在。
    -->hibernate  进入suspend to disk流程

STR和STI的最主要区别就是下面一段代码：

static int suspend_enter(suspend_state_t state, bool *wakeup)
{

…

/*
     * PM_SUSPEND_FREEZE equals
     * frozen processes + suspended devices + idle processors.
     * Thus we should invoke freeze_enter() soon after
     * all the devices are suspended.
     */
    if (state == PM_SUSPEND_FREEZE) {  如果要进入freeze状态，就会执行此段代码。
        trace_suspend_resume(TPS("machine_suspend"), state, true);
        freeze_enter();
        trace_suspend_resume(TPS("machine_suspend"), state, false);
        goto Platform_wake;  在执行结束跳转到Platform_wake，中间一段绿色代码将会被跳过。所以说freeze和standby、mem相比，多了freeze_enter，少了对non-boot CPUs、arch、syscore的操作。
    }

error = disable_nonboot_cpus();
    if (error || suspend_test(TEST_CPUS)) {
        log_suspend_abort_reason("Disabling non-boot cpus failed");
        goto Enable_cpus;
    }

arch_suspend_disable_irqs();
    BUG_ON(!irqs_disabled());

error = syscore_suspend();
    if (!error) {
        *wakeup = pm_wakeup_pending();
        if (!(suspend_test(TEST_CORE) || *wakeup)) {
            trace_suspend_resume(TPS("machine_suspend"),
                state, true);
            error = suspend_ops->enter(state);
            trace_suspend_resume(TPS("machine_suspend"),
                state, false);
            events_check_enabled = false;
        } else if (*wakeup) {
            pm_get_active_wakeup_sources(suspend_abort,
                MAX_SUSPEND_ABORT_LEN);
            log_suspend_abort_reason(suspend_abort);
            error = -EBUSY;
        }
        syscore_resume();
    }

arch_suspend_enable_irqs();
    BUG_ON(irqs_disabled());

Enable_cpus:
    enable_nonboot_cpus();

Platform_wake:
    platform_resume_noirq(state);
    dpm_resume_noirq(PMSG_RESUME);

…

}

下面分析一些每个子系统的suspend/resume。

整个suspend可以分为若干阶段，每个阶段函数—>关键节点Trace—>analyze_suspend.py解析Trace—>根据Trace时间画出Timeline图表

这样就可以分析出总的时间差异，每个阶段差异，甚至一个设备suspend/resume、一个子系统suspend/resume的时间差异。

freeze_enter

platform_suspend_begin/patform_resume_end

suspend_console/resume_console

dpm_suspend_start/dpm_resume_end

dpm_suspend_noirq/dpm_resume_noirq

disable_nonboot_cpus/enable_nonboot_cpus

arch_suspend_disable_irqs/arch_suspend_enable_irqs

syscore_suspend/syscore_resume

如何让HiKey进入STR/STI并唤醒？

可以通过配置GPIO作为唤醒源，或者通过RTC作为唤醒源，延时一定时间来唤醒。

检查是否存在/sys/class/rtc/rtc0/wakealarm，入不存在则需要打开CONFIG_RTC_DRV_PL031。

写入wakealarm的参数，表示在多少秒之后resume唤醒，退出suspend。

写mem进入state，是系统进入suspend流程。

adb root && adb remount
adb shell "echo +10 > /sys/class/rtc/rtc0/wakealarm && echo mem > /sys/power/state"

suspend/resume的latency分析手段

analyze_suspend.py v3.0

在kernel的scripts中，这个工具可以帮助内核和OS开发者优化suspend/resume时间。

在打开一系列内核选项之后，此工具就可以执行suspend操作，然后抓取dmesg和ftrace数据知道resume结束。

这些数据会按照时间线显示每个设备，并且显示占用最多suspend/resume时间的设备或者子系统的调用关系详图。

执行工具后，会根据时间生成一个子目录，里面包含：html、dmesg和原始ftrace文件。

下面简单看一下工具选项：

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 is enabled to run this tool
    -modes      List available suspend modes  显示当前支持的suspend模式
    -m mode     Mode to initiate for suspend ['freeze', 'mem', 'disk'] (default: mem)  设置进入何种模式的suspend
    -rtcwake t  Use rtcwake to autoresume after <t> seconds (default: disabled)  使用rtc来唤醒，参数是间隔时间
  [advanced]
    -f          Use ftrace to create device callgraphs (default: disabled)  基于ftrace生成调用关系图
    -filter "d1 d2 ..." Filter out all but this list of dev names
    -x2         Run two suspend/resumes back to back (default: disabled)
    -x2delay t  Minimum millisecond delay <t> between the two 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 will
                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 the test on an android device.  参数需要给出adb路径，工具就会对Android设备进行测试，并将结果pull出来。有一点需要注意，在此之前确保adb具有root权限。
                The device should already be connected and with root access.
                Commands will be executed on the device using "adb shell"
  [re-analyze data from previous runs] 针对之前测试数据重新分析
    -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

在了解了工具使用方法之后，就可以进行相关测试了。

Android

./analysze_suspend.py –modes –adb /usr/bin/adb获取当前系统支持的suspend状态。

['freeze', 'mem']

1.Android上测试STR，suspend/resume共5次，每次间隔20秒。

./analyze_suspend.py -adb  /usr/bin/adb -rtcwake 10 -multi 5 20 -f -m mem

2.Android上测试STI，suspend/resume共10次，每次间隔5秒。

./analyze_suspend.py -adb  /usr/bin/adb -rtcwake 10 -multi 5 20 -f -m freeze

测试结果可以在如下获得：

https://github.com/arnoldlu/common-use/tree/master/tools/analyze_suspend/hikey_test

存在的问题：analyze_suspend.py不支持Android的rtcwakeup和callgraph。已经在如下fix：

https://github.com/arnoldlu/common-use/blob/master/tools/analyze_suspend/analyze_suspend.py

总体对比

下面是HiKey上测试结果，可以看出两个数据都不够稳定。mem的suspend和resume平均值都比较高。

freeze相比mem的suspend/resume平均值提高了304.3ms/613.5ms。

是否suspend CPU

对比如下两幅图，明显看出mem类型的suspend关闭了除CPU0之外的所有CPU；而freeze则没有关闭任何CPU。

non-boot CPUs的suspend/resume时间就达到300ms/200ms。

同时从log中也可以看出mem和freeze的主要区别就在于是否disabling/enabling non-boot CPU。其他设备和子系统的suspend/resume时间基本一致。

[ 3385.642962] PM: suspend entry 1970-01-01 00:57:30.580909763 UTC [ 3385.649165] PM: Syncing filesystems ... done. [ 3385.661349] Freezing user space processes ... [ 3385.671207] dwc2 f72c0000.usb: dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable [ 3385.678933] dwc2 f72c0000.usb: GINNakEff triggered [ 3385.685718] (elapsed 0.019 seconds) done. [ 3385.689860] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 3385.700092] Suspending console(s) (use no_console_suspend to debug) [ 3385.736020] PM: suspend of devices complete after 27.195 msecs [ 3385.740811] PM: late suspend of devices complete after 4.765 msecs [ 3385.743919] PM: noirq suspend of devices complete after 3.090 msecs Disabling and Enabling non-boot CPUs [ 3386.209126] PM: noirq resume of devices complete after 1.865 msecs [ 3386.212066] PM: early resume of devices complete after 2.460 msecs [ 3386.234729] mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31) [ 3386.311480] mmc_host mmc0: Bus speed (slot 0) = 51756522Hz (slot req 52000000Hz, actual 51756522HZ div = 0) [ 3386.410411] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31) [ 3386.458232] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot req 25000000Hz, actual 24800000HZ div = 0) [ 3386.458729] PM: resume of devices complete after 246.646 msecs [ 3386.818770] Restarting tasks ... [ 3386.827026] done. [ 3386.844139] PM: suspend exit 1970-01-01 00:57:40.624589167 UTC

[ 3471.760265] PM: Syncing filesystems ... done. [ 3471.771897] Freezing user space processes ... [ 3471.780407] dwc2 f72c0000.usb: dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable [ 3471.788105] dwc2 f72c0000.usb: GINNakEff triggered [ 3471.794916] (elapsed 0.018 seconds) done. [ 3471.799078] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 3471.809320] Suspending console(s) (use no_console_suspend to debug) [ 3471.847947] PM: suspend of devices complete after 29.905 msecs [ 3471.852473] PM: late suspend of devices complete after 4.497 msecs [ 3471.855611] PM: noirq suspend of devices complete after 3.120 msecs [ 3481.034722] PM: noirq resume of devices complete after 1.945 msecs [ 3481.037992] PM: early resume of devices complete after 2.694 msecs [ 3481.062803] mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31) [ 3481.137795] mmc_host mmc0: Bus speed (slot 0) = 51756522Hz (slot req 52000000Hz, actual 51756522HZ div = 0) [ 3481.234796] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31) [ 3481.278601] mmc_host mmc2: Bus speed (slot 0) = 24800000Hz (slot req 25000000Hz, actual 24800000HZ div = 0) [ 3481.279396] PM: resume of devices complete after 241.388 msecs [ 3481.358513] Restarting tasks ... done. [ 3481.377766] PM: suspend exit 1970-01-01 00:59:15.332218333 UTC

resume_console节省时间

对比resume_console可以发现，mem要比freeze多210ms。

Ubuntu

此工具在Ubuntu上显示了更强大的功能。

支持了callgraph功能之后，更能清晰地分析每个设备或者子系统的suspend/resume占用的时间。

sudo ./analyze_suspend.py -rtcwake 10 -multi 5 20 -f -m mem
sudo ./analyze_suspend.py -rtcwake 10 -multi 5 20 -f -m freeze

在对比两种不同suspend模式后，发现freeze花费的时间要比mem少。这也符合预期，但是没有功耗数据?_?。

下面着重分析一下如何基于此工具分析。

工具界面总体分析

最上面显示Kernel Suspend Time和Kernel Resume Time，可以从总体上查看是否有回退或者进步。

再下面是一些缩放按钮。

然后就是基于timeline的图表，比对颜色示意图，可以清晰看出suspend prepare、suspend、suspend late、suspend irq、suspend machine、resume machine、resume irq、resume early、resume和resume complete的分布。

最下面是每个模块、子系统的详细函数调用图以及开始时间、消耗时间。

子系统、模块详细分析

选中一个模块，会在最下面显示详细的模块在suspend/resume各个阶段消费的时间，以及函数调用关系图。

缩放查看细节

ZOOM IN放大，ZOOMOUT缩小，ZOOM 1:1恢复原始尺寸。

通过在timeline图表，放大可以查看到更小的模块消耗的时间。从宏观到模块，再到函数消耗时间，逐步细化，很有利于分析。

如果发现某个函数占用时间较大，可以逐级展开。知道发现最终占用较大的函数，发现问题所在。

参考文档

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电源管理(6)_Generic PM之Suspend功能：http://www.wowotech.net/pm_subsystem/suspend_and_resume.html