蜗窝科技

@chili：OK,初步研究了下，是因为cpuidle导致，执行下面命令禁止cpuidle,就可正常快速的响应中断了 echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable

@bsp：确实啊，4*A53的ARM core，执行下面两个while后，其中2个core的cpu使用率为100%，这种情况下IR按键的识别率可以达到100%，执行一个while还是会存在误识别； while true;do : ;done & while true;do : ;done & **那么问题又来了，怎么避免不睡眠呢？IRQF_NO_SUSPEND这些中断申请的flag都试了不行，1ms的间隔都会睡眠，有办法规避或者查询到何时睡眠的吗？

wowo,很喜欢你的文章，希望多一些网络方面的文章。

wowo：请教问题，如果wake_lock_timeout同一个锁调用两次，时间不同，以哪个为准？时间长的还是按照调用顺序？

个人感觉cmwq还解决了频繁调度的问题 干同样的活，一个线程或者N个线程 都可以干，N个线程徒增调度的开销。

期待load balance和numa balance

牛逼plus,每次看都有不同理解和收获

@busdriver：一般而且，do_softirp都是raiseirqoff后，软中断执行的，为啥一直在强调taskset呢，如果不是taskset，就算do_softirq被硬中断抢占，硬中断执行完后，还是原来的cpu继续执行do_softirq吧？ 或者说，你的task就是指进程，进程又怎么执行soft_irq呢

@chili：另外也怀疑不是睡眠以及dvfs之类的，但是好像没有类似事件发生 ? 还是检查下吧，很像睡眠引起的。 你可以让系统busy起来，比如用户态 运行个while(1)，然后再测试你的程序。

探讨个非常有意思的问题，不知道linux的中断底层是怎么去处理的。 背景：用linux的gpio的中断去捕获并计算一系列1ms~2ms左右的脉宽（在中断中利用ktime_get获得时间并相减获得） 测试1：利用linux的两个gpio来测试中断latency，短接2个pin，然后利用hrtimer定期产生1ms的timer来toggle pin1的状态；然后pin2申请上升沿和下降沿中断。进入pin2中断的时间减去pin1状态改变的时间即为latency，统计多次取平均值，结果如下： CPU HZ Version times latency 4*A53 1.8G 4.14.78 10000 passes, avg. 1429 nsecs Pi 700mhz 3.6.11+ 1024 passes. avg. 3770 nsecs 【初步结论】linux虽然不是实时操作系统，但是中断延时似乎还是很小的，但是这里是平均值，可能平滑掉了一些延时非常大的凸点，于是做了第二个实验 测试2：利用linux的两个gpio来测试中断latency，短接2个pin，然后利用hrtimer定期产生us级别的timer来toggle pin1的状态；然后pin2申请上升沿和下降沿中断，记录下pin2连续两次进入中断时间间隔T2，这个T2应该近似于timer的周期T1，测试结果如下： + hrtimer 10 us toggle pin1引脚，pin2 中断间500000 次间隔超出周期 10 us +/- 5 us的 次数有 20-49/499977-499997 time range(4us-306us) + hrtimer 500 us toggle pin1引脚，pin2 中断 10000 次间隔超出周期 500 us +/- 5us的 次数有 5~8/9996~10000 time range(486 us-1006 us) + hrtimer 100 us toggle pin1引脚，pin2 中断 50000 次间隔超出周期 100 us +/- 5 us的 次数有 7~20/49990 time range(6 us- 619 us) + hrtimer 50 us toggle pin1引脚，pin2 中断 100000 次间隔超出周期 50 us +/- 5 us的 次数有 14/(100000) times 34-67 us + hrtimer 1000 us toggle pin1引脚，pin2 中断 5000 间隔超出周期 1000 us +/- 5 us的 次数有 5-16/5000 time range(489-1006) 【结论】虽然有丢中断，但是总体来说中断延时还是很小的，us基本的，基于以上两个测试，我觉得linux的gpio中断延时还是比想象中的小，于是我打算用gpio来进行IR的解码，于是有了测试3 测试3：利用一个pin接到ir信号输出，并用单边沿触发，测试脉宽周期T（IR的T的主要有1.15ms/2.25ms/9ms/13ms等，最小的都大于1ms，基于上面测试我认为正确捕获时间应该没问题）， 但是结果如下： + 每隔3s发送一个IR信号（每隔IR信号包含33个周期的IO中断），IO捕获的T打印出来，每次捕获的T都有凸点，比如T=9us + 每隔1s发送一个IR信号，大概30%概率都有凸点 + 每隔40ms发送一个IR信号，就第一个IR信号有异常的凸点，从第二个IR信号开始都是正常的T + 每隔20ms发送一个IR信号，就第一个IR信号有异常的凸点，从第二个IR信号开始都是正常的T 【结论】中断时间越长，linux越难准确捕获到，现象类似于需要一个激活状态，前面几个不准确的中断导致后面的中断都是准确的，难道底层有runtime的中断处理优化? 另外也怀疑不是睡眠以及dvfs之类的，但是好像没有类似事件发生 ， 附录具有凸点的T数据，这个在一个单独线程中打印的，中断中把时间存好： [ 96.691005] 95600663000,1012137457, d=1114 [ 96.695204] 95602281375,1012150404, d=1618 #此处捕获的实际时间比理论时间延迟了500ms，从此处开始后面的中断都延迟了500ms，所以后面T都是正确的 [ 96.699311] 95604537875,1012168456, d=2256 [ 96.703422] 95605666625,1012177486, d=1128 [ 96.707530] 95606765250,1012186274, d=1098 [ 96.711640] 95607894375,1012195308, d=1129 [ 96.715748] 95609023625,1012204342, d=1129 [ 96.719858] 95611251125,1012222162, d=2227 [ 96.723966] 95612381500,1012231204, d=1130 [ 96.728075] 95612993000,1012236097, d=611 #到此处的时候，中断没有延时，而是立即就去处理了，导致此时的时间等于理论时间，从此之后中断都是正常响应 [ 96.732184] 95615240000,1012254073, d=2247 [ 96.736204] 95616358750,1012263023, d=1118 [ 96.740313] 95619094000,1012284904, d=2735 [ 96.744420] 95620848875,1012298944, d=1754 [ 96.748542] 95623093000,1012316897, d=2244 [ 96.752652] 95624213625,1012325862, d=1120 [ 96.756758] 95626457875,1012343817, d=2244 [ 96.760867] 95628703625,1012361782, d=2245 [ 96.764973] 95630947750,1012379735, d=2244 [ 96.769094] 95633193500,1012397701, d=2245 [ 96.773204] 95635438000,1012415657, d=2244 [ 96.777314] 95637683625,1012433622, d=2245 [ 96.781433] 95639927875,1012451577, d=2244 [ 96.785545] 95642172875,1012469537, d=2245 [ 96.789653] 95643292750,1012478495, d=1119 [ 96.793775] 95644413625,1012487462, d=1120 [ 96.797883] 95645532875,1012496416, d=1119 [ 96.801991] 95646652750,1012505375, d=1119 [ 96.806106] 95647772750,1012514335, d=1120 [ 96.810216] 95648892875,1012523297, d=1120 [ 96.814323] 95650012875,1012532256, d=1120 [ 96.818444] 95651132875,1012541216, d=1120 【IR解码结果】间隔时间按一个按键，解码会失败；但是你迅速的不断按下IR按键，解码是成功的，跟上面的数据吻合，但是始终不明白为何长时间间隔的中断会捕获不准，或者说中断latency很长