1.前言
了解Linux中断子系统，同时也需要了解ARM体系结构中断处理流程；在熟悉整个软硬件架构和流程基础上，才能对流程进行细化，然后找出问题的瓶颈。《2. 梳理中断处理子系统》
但是所有的优化都离不开一个量化的过程，有个可靠、高效、可读性强的度量必不可少。《3. 一种测量中断性能手段》
最后基于此，进行中断性能的优化。《4.中断性能优化》
2. 梳理中断处理子系统
中断系统涉及到软硬件两部分，具体到ARM系统和Linux涉及到很多相关点。
硬件以Cortex-A53为基础，整个GIC架构包括两部分：CPU内部的GIC CPU Interface(Cortex-A53 Chapter 9)和CPU外部的GIC external distributor component。
《ARM Cortex-A53 MPCore Processor Technical Reference Manual》简单介绍了A53核内部的GIC CPU Interface。
《ARM Generic Interrupt Controller Architecture Specification v3/v4》详细介绍了整个GIC架构的方方面面，具体实现比如GIC-600在《GIC-600 Generic Interrupt ControllerTechnical Reference Manual》。
相关阅读记录在《阅读GIC-500 Technical Reference Manual笔记》。
软件方面可以参考蜗窝科技关于中断子系统的一系列文章《Linux中断子系统》，一共9篇文章，讲述了Linux中断的方方面面。
《综述》是一个导论性质文档，从更高层次介绍了中断相关软硬件架构；
《IRQ number和中断描述符》重点介绍了中断描述符相关数据结构以及API；
在一个中断出发之后，从CPU架构相模块进行现场保护《ARM中断处理过程》-->machine相关中断处理handler将HW Interrupt ID翻译成IRQ number《IRQ Domain介绍》-->IRQ number对应中断例程《High level irq event handler》，以及最终现场恢复流程《ARM中断处理过程》；
《驱动申请中断API》是从中断使用者角度介绍如何使用中断；中断处理的下半部包括《softirq》和《tasklet》，以及workqueue 1 2 3 4。
《GIC代码分析》重点介绍了ARM架构下中断控制器的方方面面。
3. 一种测量中断性能手段
3.1 明确评估标的
评估一个系统的中断性能，首先要明确评估那一段处理的性能。这里评估的是从中断触发开始，到执行中断例程(ISR)这段处理。
这一段从外部设备触发中断，到中断控制器，再到CPU处理，直到ISR的调用执行，涉及到软硬件的方方面面。
3.2 如何对标的进行量化
从硬件触发开始到软件ISR执行时间度量，跨软硬件。测量起来难免会有误差，尤其是两者的时间轴问题不易同步。
好在Linux有周期性Timer，周期性Timer设置一个Load值，从Load开始倒计数，计数到达0的时候触发中断。
然后重新计数，并且可以随时读取当前计数值。
在ISR中读取计数，就可以知道从上次0计数触发中断到当前消耗的Cycle数目，进而得到标的耗时。
3.3 内核实现
内核中主要注册中断、提供修改Load接口、创建proc节点。
中断相关初始化，注册中断处理函数。在ISR中进行Timer Cycle的读取。
提供修改Load接口，供动态修改Load，以达到在不同频率下测试标的的目的。
选取不同频率的load：
echo n > /proc/interrupt_stats 读取Timer中断统计信息：
cat /proc/interrupt_stats > interrupt_xxx.txt
proc文件提供设置Load和读取标的结果的接口。
//===================================================
#include <asm/uaccess.h> extern unsigned int interrupt_statiscs[][];
extern unsigned int interrupt_period_count; extern void interrupt_set_period(unsigned int cycles); static int interrupts_proc_show(struct seq_file *m, void *v)
{
int i; for(i = ; i < sizeof(interrupt_statiscs)/sizeof(interrupt_statiscs[]); i++)
seq_printf(m, "%u, %u, %u\n", interrupt_period_count, interrupt_statiscs[i][], interrupt_statiscs[i][]); return ;
} static ssize_t interrupts_proc_write(struct file *file, const char __user *user_buf, size_t count, loff_t *ppos)
{
unsigned int period_cycles;
char buf[]; if (copy_from_user(buf, user_buf, ))
return -EFAULT;
sscanf(buf, "%u", &period_cycles);
printk("%s period_cycles %u\n", __func__, period_cycles); if (period_cycles > && period_cycles < )
{
switch(period_cycles)
{
case :
period_cycles = ;
break;
case :
period_cycles = ;
break;
case :
period_cycles = ;
break;
case :
period_cycles = ;
break;
case :
period_cycles = ;
break;
default:
period_cycles = ;
} interrupt_set_period(period_cycles);
printk("%s set interrupt period to %u\n", __func__, period_cycles);
}
return ;
} static int interrupts_proc_open(struct inode *inode, struct file *file)
{
return single_open(file, interrupts_proc_show, NULL);
} static const struct file_operations interrupt_stats_proc_fops = {
.open = interrupts_proc_open,
.write = interrupts_proc_write,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
}; //=================================================== static int __init proc_uptime_init(void)
{
proc_create("uptime", , NULL, &uptime_proc_fops); proc_create("interrupt_stats", , NULL, &interrupt_stats_proc_fops);
return ;
}
module_init(proc_uptime_init);
3.4 分析结果
当前使用测试Timer是26MHz，辅助衡量Load准确行的是32768时钟计数。
26MHz的时钟，一个Cycle=38.46纳秒，这个精度已经很高了。用于衡量中断性能应该够用。
1. 将测试结果从设备中导出。第1列是当前Load数，第2列是标的耗时，第3列是辅助时钟计数。第1、2列是26MHz时钟，第3列是32K时钟。
将这些结果按照Load不同存储到interrupts_1300.txt/...文件中。
, ,
, ,
, ,
, ,
, ,
, ,
, ,
, ,
, ,
, ,
...
2. 编写分析脚本
import pandas as pd
import numpy as np
import os
import re
import matplotlib.pyplot as plt
import matplotlib
matplotlib.style.use('ggplot') cnames = ['index', 'count', 'duration'] output = []
output_cycles = [] timer_freq =
p = re.compile('^interrupts_([0-9]*).txt$') filenames = os.listdir('.')
for file in filenames:
if p.match(file):
data = []
interrupt_data = []
interrupt_stats = [] duration_data = [] interrupt_stats = pd.read_csv(file, names = cnames)--------------------读取数据源 #Show the plotting of interrupts time consumption
ts = pd.Series(interrupt_stats['count'], index=range(len(interrupt_stats['count'])))
ts.plot(title='%s'%file)
fig = plt.gcf()
fig.set_size_inches(, )
plt.ylabel('Cycles from trigger to ISR.')
plt.show() #Convert to time consumption
for i in interrupt_stats['count'].tolist():
data.append(float(i)*/timer_freq)------------------------转换成时间单位us #Calc the timer duration
for i in interrupt_stats['duration'].tolist():
duration_data.append(i) #Statistics of interrupts
interrupt_data = np.array(data)
output.append([interrupt_data.mean(), interrupt_data.max(), interrupt_data.min(), interrupt_data.std()])----每个case的统计信息
output_cycles.append([interrupt_stats['count'].mean(),
interrupt_stats['count'].max(),
interrupt_stats['count'].min(),
interrupt_stats['count'].std()])------------------------------------------------------cycles形式的统计信息 df = pd.DataFrame(output, columns=['mean(us)','max(us)','min(us)', 'std(us)'], index=['', '', '', '', ''])
df.to_csv('interrupt.csv')
pd.pivot_table(df, index='mean(us)')----------pivot table形式展示统计信息
f2 = pd.DataFrame(output_cycles, columns=['mean(us)','max(us)','min(us)', 'std(us)'], index=['1300', '2600', '26000', '260000', '2600000'])
pd.pivot_table(df2, index='mean(us)')--------pivot table形式展示统计信息
3. 结果分析
3.1 耗时图表分析
从下面5张图中可以看出标的耗时分布情况，总体来讲数据比较稳定。
- 26000/260000/2600000会有个别特别长的延时；
- 所有case的最低值比较接近在90-120左右个Cycles；
- 随着Load增加，平均耗时呈递增趋势；
- 对26000/260000/2600000修改了ylim到500，可以看出细节部分。
4.中断性能优化
中断性能优化可以分为两个阶段：中断公用部分和每个中断例程包括下半部。
4.1 中断共用部分
中断共用部分包括：架构相关代码、中断控制器驱动等。
- 提高cache命中率？
- 将相关处理代码放入cache中？
- 中断和CPU绑定？
- 级联对中断性能的影响？
- ......
4.2 每中断例程及下半部
每中断例程及下半部：首先针对中断例程，尽量短小快速、不睡眠；对下半部，采取合适的方法softirq/tasklet/workqueue。
中断例程的优化，可以通过Tracepoint中中断相关trace进行统计。
/sys/kernel/debug/tracing/events/irq/irq_handler_entry
/sys/kernel/debug/tracing/events/irq/irq_handler_exit
/sys/kernel/debug/tracing/events/irq/softirq_entry
/sys/kernel/debug/tracing/events/irq/softirq_exit
/sys/kernel/debug/tracing/events/irq/softirq_raise
下面是一个中断例程执行耗时统计信息。
平均值大说明例程需要优化，因为在中断例程执行期间是屏蔽中断的，屏蔽时间太长容易丢中断。
如果均方差大，说明中断例程内流程差异较大，可能存在隐患。
+------------------------+-------+--------+-------+-------+--------+------------------+
| name | mean | max | min | count | sum | std |
+------------------------+-------+--------+-------+-------+--------+------------------+
| dwc_otg_pcd | 0.457 | 32.196 | 0.0 | | 47.516 | 3.26191450776 |
| xxxxxxx | 0.004 | 0.031 | 0.0 | | 2.903 | 0.0106282606939 |
| dwc_otg_powerdown_up | 7.644 | 7.66 | 7.629 | | 15.289 | 0.0155 |
| icp_ps | 0.006 | 0.031 | 0.0 | | 0.031 | 0.0124 |
| xxxx_i2c. | 0.010 | 0.031 | 0.0 | | 0.459 | 0.0141861232812 |
| xxxx_timer | 0.003 | 0.092 | 0.0 | | 4.305 | 0.00947335198132 |
| dwc_otg_powerdown down | 5.264 | 6.5 | 4.028 | | 10.528 | 1.236 |
+------------------------+-------+--------+-------+-------+--------+------------------+
下面是这些中断在时间轴上的分不情况，长度表示耗时。可以看出他们的频率，以及相互之间的关系。
