最近项目上遇到一个延迟问题。问题的现象如下：
程序运行在arm上， linux版本是Linux version 5.10.35-dirty (root@Newu) (aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1）
从启动开始，每次大约在75min左右，协议栈里面运行的函数就会卡住，卡的时间一般在3-5ms（调用clock_gettime()看的卡顿时间.）
最开始怀疑应用程序的问题，针对问题进行的业务模型简化，在隔离的独立的core上单独只跑出问题的线程，这个线程设置为schd_FIFO, 优先级设置为99. 发现还是在75min卡顿（可能卡顿在不同的函数，或者不同赋值语句地方。）。例如：
clock_gettime(CLOCK_REALTIME,&starttime);
Fun(); //空函数
clock_gettime(CLOCK_REALTIME,&endtime); 两个时间差相减就是3-5ms. 这个空函数肯定不需要这么久。不清楚这个时候系统出了什么问题。
在75min卡顿后，后面可能出现卡顿多次，也可能一直不出现卡顿，没有周期性。
对业务程序进行极致版简化后问题依然出现，接着怀疑是否系统有问题。后面通过ftrace来分析内核调用过程，显示每次在73min左右会出现do_mem_abort出发缺页流程。如下所示
但是在进行缺页处理的时候，拿不到mmap_sew这个锁，在这个地方卡住了几ms. 但是是谁持有了这把锁， 怎么去优化，这些都是linux 内核知识。
从网上找了两篇关于这方面的介绍：
mmap_sem信号量死锁故障分析
https://blog.csdn.net/lijzheng/article/details/23216633
内核mmap_sem锁的危害和相关优化
https://blog.csdn.net/buhui912/article/details/124984815
但由于缺少这方面的知识，没有继续往下查，而是转去优化mem这方面的问题。
标签：sew,clock,mmap,问题,75min,卡顿,延迟 From： https://www.cnblogs.com/beilou310/p/16879643.html