Linux性能优化实践(1): 进程长时间不被调度执行案例

文章目录

  • 1. 前言
  • 2. 分析环境
  • 3. 问题描述
  • 4. 问题分析
    • 4.1 代码分析
    • 4.2 程序日志分析
      • 4.2.1 CPU 频率变换引发的抖动?
      • 4.2.2 中断导致的调度延迟?
  • 5. 结语

1. 前言

限于作者能力水平,本文可能存在谬误,因此而给读者带来的损失,作者不做任何承诺。

2. 分析环境

1. SoC: T507, Cortex-A53, 4核, 1.5GHz(最高频)
2. 系统: Linux 4.9/Ubuntu 18.04

3. 问题描述

有一个简单的按键驱动,采样 GPIO 上升或下降沿中断信号。按键信号通过 PLC设备25Hz 的固定频率触发;然后用户空间读取按键事件,测试发现,3万次左右就漏掉了接近 190 次按键事件。

4. 问题分析

4.1 代码分析

内核按键驱动非常简单,核心逻辑概要如下:

static irqreturn_t xxx_gpio_key_isr(int irq, void *dev_id)
{
	...
	input_event(input, EV_KEY, code, state);
	input_sync(input); // 唤醒可能的睡眠等待读者进程
	...
	return IRQ_HANDLED;
}

用户空间读取按键事件的代码,核心逻辑概要如下:

int fd;
fd_set fds;
struct input_event event;
int down_count = 0;

fd = open("/dev/input/event1", O_RDWR);
for (;;) {
	FD_ZERO(&fds);
	FD_SET(fd, &fds);
	if (select(fd + 1, &fds, NULL, NULL, NULL) < 0) { // 有事件数据立即返回,否则睡眠等待直到有事件数据到来
		perror("select");
		break;
	}
	
	memset(&event, 0, sizeof(event));
	if (read(fd, &event, sizeof(event)) < 0) {
		perror("read");
		break;
	}

	if (event.type == EV_KEY) {
		if (event.code == KEY_DOWN) { // 驱动上报的是 Down 键
			if (event.value) { // 下降沿事件上报: 理解为按键按下
				++down_count;
				LOGI("event.value: %d, count = %d/%d\n", event.value, down_count, trigger_count());
			} else { // 上升沿事件上报: 理解为按键松开
				LOGI("event.value = %d\n", event.value);
			}
		}
	}
}
close(fd);

其中, LOGI() 是封装的一个日志接口,其输出在日志内容前加上了时间戳、线程名和线程PID,后面从日志中可以看到;trigger_count() 返回 PLC设备 实际触发的按键事件次数(至于怎么做的,读者不用纠结,了解这点就可以了)。另外,上面的按键事件代码用在一个比较复杂的应用程序中,但分析的时候,为排除其它代码的影响,已经将该段代码独立到一个测试程序中,该测试程序仅包含上述代码。
分析下了驱动和测试代码,没发现什么问题,这代码毕竟是一目了然。

4.2 程序日志分析

由于程序日志加入了时间戳、线程名和线程PID,所以很容易发现线程每两次被调度执行之间的大概时间间隔,从程序日志里,发现如下异常日志:

[809.934931608] <I> <test.2867> event.value: 1, count = 18156/18156
[811.244779323] <I> <test.2867> event.value: 0
[809.246744615] <I> <test.2867> event.value: 1, count = 18157/18188

日志中的时间戳,格式为 秒.纳秒 ,上面 第1行 和 第2行 日志的时间戳,相差为 1309.847715 毫秒,按每秒 25 次按键计算,每两次按键相隔 1000 / 25 = 40ms ,所以 1309.847715 毫秒 约有 1309.847715 / 40 = 32 次按键事件,和日志里面的 count = 18157/18188 统计是对应的:18188 - 18157 = 31。不要为不是 32 而奇怪,日志的打印也是会存在一点消耗的,这没有问题。看到这里,首先考虑是不是按键事件上报的源头,中断处理不及时,但通过 cat /proc/interrupts 查看,所有的按键中断都被捕捉上报了:

# cat /proc/interrupts
120:     36376          0          0          0  sunxi_pio_edge 103 Edge      gpio_key_drv

可以看到,处理了 36376 次中断(包括上升沿和下降沿),36376 / 2 = 18188 和程序日志里的实际按键事件次数是对应的。既然没有漏掉按键中断,就意味着按键事件都上报了,按理每次都会唤醒应用读取事件才对,但为什么应用日志里面会有 1,309.847715 毫秒 的间隙,这可是 1秒多,进程的唤醒调度延迟,再怎么也不应该造成这么久的延迟,简直太不可思议了!

4.2.1 CPU 频率变换引发的抖动?

查看了下 Ubuntu 18.04 配置的 CPU 频率策略

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
interactive
interactive
interactive
interactive

嗯,可能会产生 CPU 频率的切换,于是打开了内核 cpufreq 的相关日志,再次进行测试,发现如下内核日志:

[  586.352163] cpufreq: notification 1 of frequency transition to 792000 kHz
[  586.352170] cpufreq: FREQ: 792000 - CPU: 1
[  586.352180] cpufreq: notification 1 of frequency transition to 792000 kHz
[  586.352188] cpufreq: FREQ: 792000 - CPU: 2
[  586.352198] cpufreq: notification 1 of frequency transition to 792000 kHz
[  586.352205] cpufreq: FREQ: 792000 - CPU: 3
[  586.371136] cpufreq: target for CPU 0: 1008000 kHz, relation 1, requested 1008000 kHz
[  586.371147] cpufreq: __target_index: cpu: 0, oldfreq: 792000, new freq: 1008000
[  586.371158] cpufreq: cpus 0-3 cur freq/max freq 1008000/1512000 kHz freq scale 682
[  586.371168] cpufreq: notification 0 of frequency transition to 1008000 kHz
[  586.371176] cpufreq: notification 0 of frequency transition to 1008000 kHz
[  586.371185] cpufreq: notification 0 of frequency transition to 1008000 kHz
[  586.371193] cpufreq: notification 0 of frequency transition to 1008000 kHz
[  586.373613] cpufreq: notification 1 of frequency transition to 1008000 kHz
[  586.373620] cpufreq: FREQ: 1008000 - CPU: 0
[  586.373629] cpufreq: notification 1 of frequency transition to 1008000 kHz
[  586.373635] cpufreq: FREQ: 1008000 - CPU: 1
[  586.373643] cpufreq: notification 1 of frequency transition to 1008000 kHz
[  586.373649] cpufreq: FREQ: 1008000 - CPU: 2
[  586.373657] cpufreq: notification 1 of frequency transition to 1008000 kHz
[  586.373662] cpufreq: FREQ: 1008000 - CPU: 3
[  586.474473] cpufreq: target for CPU 0: 480000 kHz, relation 1, requested 480000 kHz
[  586.474482] cpufreq: __target_index: cpu: 0, oldfreq: 1008000, new freq: 480000
[  586.474491] cpufreq: cpus 0-3 cur freq/max freq 480000/1512000 kHz freq scale 325
[  586.474498] cpufreq: notification 0 of frequency transition to 480000 kHz
[  586.474505] cpufreq: notification 0 of frequency transition to 480000 kHz
[  586.474511] cpufreq: notification 0 of frequency transition to 480000 kHz
[  586.474518] cpufreq: notification 0 of frequency transition to 480000 kHz
[  586.477606] cpufreq: notification 1 of frequency transition to 480000 kHz
[  586.477621] cpufreq: FREQ: 480000 - CPU: 0
[  586.477640] cpufreq: notification 1 of frequency transition to 480000 kHz
[  586.477653] cpufreq: FREQ: 480000 - CPU: 1
[  586.477669] cpufreq: notification 1 of frequency transition to 480000 kHz
[  586.477682] cpufreq: FREQ: 480000 - CPU: 2
[  586.477697] cpufreq: notification 1 of frequency transition to 480000 kHz
[  586.477709] cpufreq: FREQ: 480000 - CPU: 3
[  610.431310] cpufreq: target for CPU 0: 600000 kHz, relation 1, requested 600000 kHz
[  610.431333] cpufreq: __target_index: cpu: 0, oldfreq: 480000, new freq: 600000

呵呵,这频率简直在跳舞,最低都降到了 480000 Hz ,鉴于此,于是将 CPU 频率策略调整为 performance ,以最高频率 1.5 GHz 来跑,同时将 PLC设备 的按键触发频率提高到了 60Hz(毕竟4核,1.5GHz),看情况会变成怎样。

# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
# echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
# echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
1512000
1512000
1512000
1512000

测试结果发现,情况得到了很大的改善,但还是会偶尔漏掉按键事件,看程序日志:

[3122.791343360] <I> <test.2867> event.value: 1, count = 113659/113659
[3122.972479211] <I> <test.2867> event.value: 0

两个时间戳,相差了 181.135851 毫秒!查看内核日志,没有发现 CPU 频率变化的日志信息。读到这里,有的童鞋可能有疑问了,既然都调整成了 performance 模式,为什么还要观察内核日志中 CPU 频率变化信息,怎么还可能降频?事实上,在带有温控监测模块的情形下,即使是 CPU 运行于 performance 模式,也有可能出现因温度过高导致的降频,但这里的情形显然不是。

4.2.2 中断导致的调度延迟?

因为是偶发的漏掉按键事件,那可能是一些不规律的事件的引起的,中断是一个首先要考察的对象,查看了下系统的中断发生状况:

           CPU0       CPU1       CPU2       CPU3       
  3:     105999     206753     224680     246969  wakeupgen  48 Level     sun4i_timer0
  6:    8103107    5279139    8122634    4230346     GIC-0  27 Level     arch_timer
  8:          0          0          0          0  wakeupgen  61 Level     30f0000.iommu
120:     285180          0          0          0  sunxi_pio_edge 103 Edge      gpio_key_drv
273:          0          0          0          0  wakeupgen  42 Level     3002000.dma-controller
276:          0          0          0          0  wakeupgen 104 Level     rtc
278:          0          0          0          0  wakeupgen  93 Level     cedar_dev
279:          0          0          0          0  wakeupgen  90 Level     1480000.g2d
280:        472          0          0          0  wakeupgen   0 Level     uart0
284:       6278          0          0          0  wakeupgen 105 Level     twi5
285:    3421998          0          0          0  wakeupgen   7 Level     twi1
286:          4          0          0          0  wakeupgen   9 Level     twi3
290:          0          0          0          0  wakeupgen  28 Level     ehci_hcd:usb1
291:          0          0          0          0  wakeupgen  29 Level     ohci_hcd:usb4
292:          0          0          0          0  wakeupgen  30 Level     ehci_hcd:usb2
293:          0          0          0          0  wakeupgen  31 Level     ohci_hcd:usb5
294:          0          0          0          0  wakeupgen  32 Level     ehci_hcd:usb3
295:          0          0          0          0  wakeupgen  33 Level     ohci_hcd:usb6
296:          0          0          0          0  wakeupgen  13 Level     spi1
299:      22759          0          0          0  wakeupgen  37 Level     sunxi-mmc2
300:          7          0          0          0  wakeupgen  36 Level     sunxi-mmc1
304:          0          0          0          0  wakeupgen  66 Level     dispaly
308:        240          0          0          0  wakeupgen  75 Level     vin_cci
311:          0          0          0          0  wakeupgen  69 Level     vinc0
312:          0          0          0          0  wakeupgen  70 Level     vinc1
313:          0          0          0          0  wakeupgen  71 Level     vinc2
314:          0          0          0          0  wakeupgen  72 Level     vinc3
315:          0          0          0          0  wakeupgen  79 Level     vinc4
316:          0          0          0          0  wakeupgen  80 Level     vinc5
319:          0          0          0          0  wakeupgen  89 Level     1420000.deinterlace
323:     201292          0          0          0  wakeupgen  14 Level     gmac0
330:          0          0          0          0  sunxi-8i-nmi   0 Level     axp858_irq_chip
342:          0          0          0          0  axp858_irq_chip  11 Edge      axp20x-pek-dbf
343:          0          0          0          0  axp858_irq_chip  12 Edge      axp20x-pek-dbr
IPI0:    155361     229366     208753     236313       Rescheduling interrupts
IPI1:        69        520        585        539       Function call interrupts
IPI2:         0          0          0          0       CPU stop interrupts
IPI3:      4622       9795      13988      15958       Timer broadcast interrupts
IPI4:     12449      11302      10855      12823       IRQ work interrupts
IPI5:         0          0          0          0       CPU wake-up interrupts
Err:          0

发现了吧,SPI 中断基本都集中在 CPU 核 0 上。鉴于此,有了这样的一个猜想:某段时间内,我们的测试程序被调度到 CPU 0 上执行,但由于此段时间中断频发,导致程序始终无法被调度去执行读取按键事件的代码;等到再被调度去读取按键事件时,Input 子系统缓冲里、前面的按键事件数据已经被新事件数据覆盖了,再也无法读取到。此段期间,测试程序一直在 CPU 0 上接受调度。有了想法,就去验证,于是通过 taskset 命令对测试程序进行绑核操作,不让测试程序在中断压力大的 CPU 0 上运行

# taskset -p 0xe 2867
# taskset -cp 2867
pid 2867's current affinity list: 1-3

重新测试500万次,没有再发现漏掉按键事件的情况,看样子优化方向应该是对的。

5. 结语

小结一下,导致问题的原因,包括两点:

1. CPU 频率变换导致的调度延迟
2. CPU 中断引发的调度延迟

如果经过前面的优化,仍然有丢失按键事件的问题,继续优化的方向包括:

1. 调整进程优先级
2. 调整为实时进程
3. 通过 cgroup 分配独立的核给程序使用

本文分析没有使用诸如 ftrace, perf, eBPF 之类的工具,事实上,笔者认为,在有源码的情形下,分析源码本身,就是最有效的分析方法,带上时间戳、线程名和其PID,简单朴素的 printf() 调试插桩,在大多数情形下,都是很好的调试工具。像 ftrace, perf, eBPF 之类的工具,都是一种逆向的分析方法,是不得已的选择,而且这些工具,在分析性能的时候,都是计算被关注代码段前后时间消耗,和本文使用的方法并无本质的差别,即使是调试程序流程,printf() 仍然也是很好的选择。当然,printf() 也有它不适用的场合。
另外,上面的观察中,发现 SPI 中断总是集中在 CPU 0 上,具体原因可参考博文:Linux: ARM GIC仅中断CPU 0问题分析 。
本文涉及到中断相关内容,可参考博文:Linux: 中断实现简析
涉及到的输入子系统相关内容,可参考博文:Linux输入子系统简析

你可能感兴趣的:(#,追踪,&,调试,&,性能,linux,性能优化,调度延迟)