Ftrace分析cpu idle被周期唤醒原因

已于 2023-02-09 18:54:28 修改
阅读量730 收藏 6
点赞数 2
分类专栏： Linux debug linux 文章标签： linux
于 2023-01-31 20:40:41 首次发布
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/lunhui2016/article/details/128823227
版权

1. 背景介绍

Ftrace的配置和使用，参考链接：
https://blog.csdn.net/lunhui2016/article/details/88677464

在Linux系统中，为了降低功耗，基本都会配置上CONFIG_NO_HZ_IDLE选项，表示如果CPU上啥task都没有跑，一般会跑到一个idle task，在进入idle task前，会把该cpu的tick关闭，用于降低功耗，避免频繁的tick将其cpu从idle中唤醒，导致增加功耗，但在实际项目中发现，发现cpu进入idle后，会被一个固定周期的tick中断将cpu唤醒出来，进而导致idle进出过于频繁，增加了系统的功耗。

本文介绍利用Ftrace提共的trace event来分析cpu在进入idle后，被周期性tick中断打断的原因并解决，以降低产品功耗。

2. 问题分析

2.1 idle下的tick中断统计

while [ 1 ]; do cat /proc/interrupts | head -n 2; sleep 1; done &

           CPU0       CPU1       CPU2       CPU3
  4:       7791       2456        462       4020     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       7829       2480        463       4051     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       7861       2510        463       4072     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       7896       2530        463       4090     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       7930       2550        463       4115     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       7967       2579        464       4143     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8005       2611        464       4176     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8038       2638        464       4199     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8074       2656        464       4228     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8111       2675        465       4256     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8147       2694        465       4283     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8184       2727        465       4316     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8217       2747        465       4338     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8251       2766        466       4363     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8288       2784        466       4391     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8325       2811        466       4418     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8361       2836        466       4450     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8400       2859        467       4473     GIC-0  27 Level     arch_timer
           CPU0       CPU1       CPU2       CPU3
  4:       8437       2880        467       4497     GIC-0  27 Level     arch_timer

从统计中可以看出，cpu2对应的tick中断，基本隔4s左右，就会触发一次，导致cpu2从idle中退出

2.2 idle下的tick中断产生原因分析

使用ftrace跟踪timer相关的event:

  • 配置ftrace event相关信息
:以可读写方式重新挂载根文件系统
adb shell "mount -o remount,rw /"

:Ftrace设置
adb shell "echo 0 > /sys/kernel/debug/tracing/tracing_on"
adb shell "echo > /sys/kernel/debug/tracing/trace"

:Only trace cpu2
adb shell "echo 4 > /sys/kernel/debug/tracing/tracing_cpumask"

:Ftrace hrtimer setup
adb shell "echo 1 > /sys/kernel/debug/tracing/events/timer/hrtimer_start/enable"
adb shell "echo traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_start/trigger"
adb shell "echo 1 > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_entry/enable"
adb shell "echo traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_entry/trigger"
adb shell "echo 1 > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_exit/enable"
adb shell "echo traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_exit/trigger"
adb shell "echo 1 > /sys/kernel/debug/tracing/events/timer/hrtimer_cancel/enable"
adb shell "echo traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_cancel/trigger"

pause

:restore Ftrace config
adb shell "echo 0 > /sys/kernel/debug/tracing/events/timer/hrtimer_start/enable"
adb shell "echo !traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_start/trigger"
adb shell "echo 0 > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_entry/enable"
adb shell "echo !traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_entry/trigger"
adb shell "echo 0 > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_exit/enable"
adb shell "echo !traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_expire_exit/trigger"
adb shell "echo 0 > /sys/kernel/debug/tracing/events/timer/hrtimer_cancel/enable"
adb shell "echo !traceon > /sys/kernel/debug/tracing/events/timer/hrtimer_cancel/trigger"
adb shell "echo 0 > /sys/kernel/debug/tracing/tracing_on"
  • 使能ftrace并且输出跟踪结果
# echo 1 > /sys/kernel/debug/tracing/tracing_on ;cat /sys/kernel/debug/tracing/t
race
# tracer: nop
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | /  _----=> need-resched_lazy
#                            || / _---=> hardirq/softirq
#                            ||| / _--=> preempt-depth
#                            |||| /     delay
#           TASK-PID   CPU#  |||||    TIMESTAMP  FUNCTION
#              | |       |   |||||       |         |
          <idle>-0     [002] d..h2..    48.050752: hrtimer_cancel: hrtimer=ffff80006ff1f888
          <idle>-0     [002] d..h1..    48.050757: hrtimer_expire_entry: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn now=48046003339
          <idle>-0     [002] dn.h1..    48.050761: hrtimer_expire_exit: hrtimer=ffff80006ff1f888
          <idle>-0     [002] dn.h2..    48.050762: hrtimer_start: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn expires=52046000000 softexpires=52046000000 mode=ABS
          <idle>-0     [002] dn..2..    48.050765: hrtimer_start: hrtimer=ffff80006ff1f730 function=tick_sched_timer expires=48047000000 softexpires=48047000000 mode=ABS|PINNED
          <idle>-0     [002] d...2..    48.050776: hrtimer_cancel: hrtimer=ffff80006ff1f730
          <idle>-0     [002] d..h2..    52.050750: hrtimer_cancel: hrtimer=ffff80006ff1f888
          <idle>-0     [002] d..h1..    52.050751: hrtimer_expire_entry: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn now=52046003339
          <idle>-0     [002] dn.h1..    52.050753: hrtimer_expire_exit: hrtimer=ffff80006ff1f888
          <idle>-0     [002] dn.h2..    52.050754: hrtimer_start: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn expires=56046000000 softexpires=56046000000 mode=ABS
          <idle>-0     [002] dn..2..    52.050757: hrtimer_start: hrtimer=ffff80006ff1f730 function=tick_sched_timer expires=52047000000 softexpires=52047000000 mode=ABS|PINNED
          <idle>-0     [002] d...2..    52.050766: hrtimer_cancel: hrtimer=ffff80006ff1f730
          <idle>-0     [002] d..h2..    56.050750: hrtimer_cancel: hrtimer=ffff80006ff1f888
          <idle>-0     [002] d..h1..    56.050751: hrtimer_expire_entry: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn now=56046003673
          <idle>-0     [002] dn.h1..    56.050754: hrtimer_expire_exit: hrtimer=ffff80006ff1f888
          <idle>-0     [002] dn.h2..    56.050754: hrtimer_start: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn expires=60046000000 softexpires=60046000000 mode=ABS
          <idle>-0     [002] dn..2..    56.050757: hrtimer_start: hrtimer=ffff80006ff1f730 function=tick_sched_timer expires=56047000000 softexpires=56047000000 mode=ABS|PINNED
          <idle>-0     [002] d...2..    56.050766: hrtimer_cancel: hrtimer=ffff80006ff1f730
          <idle>-0     [002] d..h2..    60.050749: hrtimer_cancel: hrtimer=ffff80006ff1f888
          <idle>-0     [002] d..h1..    60.050750: hrtimer_expire_entry: hrtimer=ffff80006ff1f888 function=watchdog_timer_fn now=60046003007
...

从Ftrace抓取的log可以看到，有个watchdog timer会周期性触发，时间也是4s左右，跟现象一样，因此很可能就是这个timer导致的了

搜索源码发现，是开启了CONFIG_SOFTLOCKUP_DETECTOR导致，代码如下所示：

/* watchdog kicker functions */
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
{
	unsigned long touch_ts = __this_cpu_read(watchdog_touch_ts);
	struct pt_regs *regs = get_irq_regs();
	int duration;
	int softlockup_all_cpu_backtrace = sysctl_softlockup_all_cpu_backtrace;

	if (!watchdog_enabled)
		return HRTIMER_NORESTART;

	/* kick the hardlockup detector */
	watchdog_interrupt_count();

	/* kick the softlockup detector */
	wake_up_process(__this_cpu_read(softlockup_watchdog));

	/* .. and repeat */
	hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));\
    ...
}

其中softlockup检查的采样周期计算如下所示：

/*
 * Hard-lockup warnings should be triggered after just a few seconds. Soft-
 * lockups can have false positives under extreme conditions. So we generally
 * want a higher threshold for soft lockups than for hard lockups. So we couple
 * the thresholds with a factor: we make the soft threshold twice the amount of
 * time the hard threshold is.
 */
static int get_softlockup_thresh(void)
{
	return watchdog_thresh * 2;
}

static void set_sample_period(void)
{
	/*
	 * convert watchdog_thresh from seconds to ns
	 * the divide by 5 is to give hrtimer several chances (two
	 * or three with the current relation between the soft
	 * and hard thresholds) to increment before the
	 * hardlockup detector generates a warning
	 */
	sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5);
	watchdog_update_hrtimer_threshold(sample_period);
}

其中watchdog_thresh是一个全局变量，默认值为10，如下所示：

unsigned long __read_mostly watchdog_enabled;
int __read_mostly watchdog_user_enabled = 1;
int __read_mostly nmi_watchdog_user_enabled = NMI_WATCHDOG_DEFAULT;
int __read_mostly soft_watchdog_user_enabled = 1;
int __read_mostly watchdog_thresh = 10;
int __read_mostly nmi_watchdog_available;

可以算出，这个hrtimer的周期也是4s，符号Ftrace抓取的log情况

3. 问题解决

在开发过程中，打开CONFIG_SOFTLOCKUP_DETECTOR这个配置，是方便开发者进行系统问题定位和分析的，如果进行release，则该配置可以关闭，因此把这个配置关闭即可。

lunhui2016
关注
  • 2
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Idle:保持计算机空闲和唤醒的另一种方法
04-21
空闲 使计算机保持空闲和唤醒的另一种方法。 ＃我对这个产品感兴趣。 它是如何工作的？ 空闲工具集（Idle.vbs，Idlecheck.bat和Idlestop.bat）通过每6秒钟两次按下numlock键来使计算机保持唤醒状态。 时间间隔可根据您的需要进行配置。 它仅用11行代码即可完成此操作。 通过两次敲击numlock键，它会返回到其原始状态，但是在执行此操作的过程中，它会注册一个击键（实际上是2次击键），这会唤醒您的计算机。 ＃我被卖了！ 如何获得空闲工具集？ 有很多选择。 您可以将文件从此存储库下载到计算机上的文件夹中 您可以将存储库克隆到本地计算机上 您可以在计算机上创建这3个文件（Idle.vbs，Idlestop.bat和Idlecheck.bat），然后重新编写这些文件中包含的11行代码。 应该需要2分钟的时间。 ＃我的系统上有文件。 接下来是什么？ 要开始空闲
ftrace-分析.doc
03-09
【ftrace】是Linux内核中的一个动态跟踪框架，它允许开发者在运行时对内核进行函数级的追踪，以获取详细的性能分析数据。在龙芯64位处理器平台上，ftrace的实现原理主要涉及以下几个方面： 1. **函数注入**： 当...
一文搞懂linux cpu idle
生活需要深度
09-25 2519
接下来是计算下一次选择校正因子（correction factor）的值，将上一次的校正因子先衰减一次，然后加上一个predicted_us和next_timer_us的比值new_factor += RESOLUTION * measured_us / data->next_timer_us;当CPU idle时，根据预测的idle时间、功耗受益大小、恢复的时间长短，选用一个idle状态，比如进入wfi，关掉CPU的arch timer以便降低功耗，当有中断触发时，CPU又会恢复回来。
idle thread状态、编译选项CONFIG_CPU_IDLE
weixin_48185168的博客
10-06 296
介绍在arm64架构中wfi、hlt和nop这三种汇编指令的区别，介绍了CONFIG_CPU_IDLE编译选项对选择idle state的影响。
linux性能工具--ftrace使用
lzqxs89的专栏
05-26 595
trace event 就是利用 ftrace 框架，实现低性能损耗，对执行流无影响的一种信息输出机制。不开启没有性能损耗开启后不影响代码流程不需要重新编译内核即可获取 debug 信息。
性能优化CPU
warrah 南极狼
04-02 389
Charlie Hunt、Binu John著《JAVA性能优化权威指南》，提到现代操作系统自带的CPU使用率监控工具只能报告CPU使用率，没有CPU指令占用CPU时钟周期的占比。 即使CPU在等待内存中的数据，操作系统工具仍然会报告CPU繁忙，这种情况通常称为停滞（stall），一旦发生停滞，就会浪费时钟周期。 看到这篇文章CPU使用率度量指标是扯淡！，下面这种图说的也是这个意思。 提高应用性能的策略就是减少停滞或改善CPU高速缓存使用率。 减少CPU在等待内存数据时浪费的时间周期。故而也就有了，CPU
Ftrace Kernel Hooks-More than just tracing.pdf
10-22
Ftrace 是 Linux 内核中的一种追踪机制，能够记录和分析内核中的函数调用过程。Ftrace 的主要组件包括 Function Tracer、Function Graph Tracer、Function Profiler、Stack Tracer 等。这些组件可以帮助开发者和系统...
catapult,图形化ftrace log
11-14
catapult,图形化ftrace log cat /sys/kernel/tracing/trace > /data/local/tmp/trace_output trace_output 以文本形式提供跟踪记录，可使用 Catapult 将其可视化 catapult/tracing/bin/trace2html ~/path/to/trace...
ftrace使用简介
11-24
ftrace 还支持许多其他功能，如延迟分析、自定义事件和回调函数，可以帮助开发者深入洞察内核行为，优化性能，并解决复杂的问题。不断探索和利用 ftrace 的潜力，将有助于提升 Linux 内核的调试和优化能力。
ftrace手册
09-24
Linux内核中的ftrace（Function Trace）是一种强大的动态追踪工具，它允许开发者和系统管理员对内核行为进行详细的分析和调试。ftrace提供了一个灵活的框架，可以追踪各种内核事件，包括函数调用、定时事件、中断...
Using RCU‘s CPU Stall Detector(待更新)
win9
07-28 3418
文章目录是什么原因导致RCU CPU Stall 警告？Fine-Tuning the RCU CPU Stall Detector解读RCU's CPU Stall Detector "Splats" 本文首先讨论RCU的CPU Stall Detector可以定位哪些类型的问题，然后讨论内核参数和Kconfig选项，它们可以用来微调Detector的操作。最后，本文解释了stall Detector的“splat”格式。 是什么原因导致RCU CPU Stall 警告？ 所以你的内核打印了一个RCU C
RCU检测CPU stall的原理
热门推荐
对的时间点
11-22 1万+
在系统中，有时可能会看到如下警告： INFO: rcu_sched self-detected stall on CPU 0-...: (9999 ticks this GP) idle=cee/140000000000001/0 softirq=64858/64858 fqs=4891 (t=10000 jiffies g=13416 c=13415 q=68) Task dump for CPU 0: my_debug_1 R running task 这是rcu的cpu
Linux Cpuidle介绍
内核工匠
07-08 5395
一、引入背景先来看一个抖音场景下面的功耗表现，这个是功耗分解板拆解出来的某一款手机cpu的核压和功率，会发现它们它们的数值不是一直保持在高位，有些时间会下降到很低。这个时候有人会说下降是因为cpu上面没有任务在执行了，所以cpu就不需要工作造成功耗损失，那么就引出来一件事情，当cpu上面没有任务执行的时候，系统是如何进行cpu管理的，如果在没有任务的时候只是单纯的关闭cp...
Linux cpu Idle机制
最新发布
专注于系统快稳省领域
01-02 3919
cpu idleu作用：在cpu空闲状态下进入低功耗模式，从而达到节省功耗的目的。idle低功耗模式主要的省电策略：1）wfi 2）关闭cpu时钟 3）关闭设备等实现原理：linux内核初始化时，会为每个cpu创建一个idle线程，当该cpu处于空闲状态，即cpu上没有可调度的线程或可执行的task，此时调度器会选择idle线程执行，进入idle低功耗状态。而idle状态又分为不同的层级，越深的层及省电越优，但系统恢复越慢，因此需要结合用户需求，选择进入哪个层级的idle状态。
【Linux kernel/CPU idle】CPU Idle ----framework
mmbb26的博客
10-25 1813
当cpu没有执行任务的时候，系统是如何管理cpu的？如果没有运行任务直接对cpu下电，确实做到低功耗了，但会导致下次跑任务，CPU启动太慢会导致性能太拉跨。
CPUIDLE 之低功耗定时器
u012418573的博客
07-18 1489
在 Linux 操作系统中，Idle 进程（又叫 Swapper 进程）的 pid 号是 0，是所有进程的祖先，它是在 Linux 初始化阶段从无到有创建的一个内核线程。stark_kernel() 函数初始化内核需要的所有数据结构，激活中断，创建另一个叫进程 1 的内核线程（init 进程）。新创建内核线程的 PID 为 1，并与进程 0 共享进程所有的内核数据结构。创建 init 进程后，进程
优化实时性能
白杨谷的博客
08-13 6936
NFV的提出，为运营商提供了一个新的选择，不在有限于设备提供商。将各个网络模块运行于VM或者容器中，但是由于引入了hypervisor，延迟必定会比直接运行在物理机上要大一些，本文记录了如何在VM中通过设置内核启动参数降低程序调度的延迟。 Linux Kernel 通用内核 在spinlock、irq上下文方面无法抢占，因此即使高优先级任务被唤醒到得以执行的时间并不能完全确定。正是因为这个执行时间的不确定性， 实时内核 实时系统分为硬实时和软实时，区别主要在于，软实时是统计上的实时，保证一定百分比
【Linux kernel/CPU idle】CPU Idle ----menu governor
mmbb26的博客
10-26 1032
Linux kernel的framework有两种比较固定的抽象模式：模式1，provider/consumer模式，interrupt、clock、timer、regulator等大多数的framework是这种模式。它的特点是，这个硬件模块是为其它一个或多个模块服务的，因而framework需要从对上（consumer）和对下（provider）两个角度进行软件抽象；模式2，driver/governor模式，本文所描述的cpuidle framework即是这种模式。
CPUIDLE
relax33的博客
12-12 2047
cpuidle
深入探索Ftrace：超越追踪功能
2. **Perf**：Perf是Linux的一个性能分析工具，它可以与Ftrace协同工作，提供更高级别的统计和分析功能，如CPU周期计数、采样事件等。 3. **Pstore**：Pstore是内核日志持久化存储的子系统，可以将重要的系统事件或...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值