Linux中断响应，使用Linux信号传送机制，内核层发送信号至用户层
要求为：ARM外部GPIO接收下降沿硬件中断，在中断回调函数中发送信号SIGIO给用户层，用户层异步接收到信号后在自身回调函数中做出一部分简单处理。具体要求很简单：外部4mS一个硬件中断（GPIO），如何实时传入Linux用户层，并快速处理，对这个中断事件的处理主要是在用户层的操作（有一些消息分发，进程管理之类的工作需要外部中断来触发）。
内核层可通过kill_fasync异步发送，kill_fasync发送方法网上资料很多，借用即可。
用户层通过signal(MYSIG, sig_handler)绑定信号和回调函数
共一下几个步骤：
signal(MYSIG, sig_handler);
fcntl(fd, F_SETOWN, getpid());
f_flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL,f_flags | O_NONBLOCK | FASYNC);
fcntl(fd, F_SETSIG, MYSIG);//如果要发送实时信号（MYSIG可自行定义），则需要通过fcntl设置
现测试后，发现信号传送正常。如果要周期性的接收信号，比如4mS一个GPIO中断，就需要对应时间里内核发送信号（相同信号）至用户层，用户层及时接收到相应信号。
测试遇到的问题是：周期性的信号交互并不是每次都能实时的响应，会出现中断事件未响应的现象。即GPIO的中断事件并不能在用户层实时响应（4mS的中断并不是很快），对于这种现象，不知道大家有没有好的解决办法，或者能够指出我所犯的错误。
最后在进程中pause等待信号，这样就不会出现中断事件传递过程中丢失的现象，但是在实际应用中又是不能pause的。
另外，为了满足要求，又尝试使用了一下input子系统，使用input_event来上报中断事件，这样起单个进程跑是不会丢失事件的，但是，如果增加几个线程或者进程来调度的话就会出现事件丢失的现象，在优先级方面，处理事件的线程的优先级是最高的。
还望同志们给点意见，谢谢！ HZ会影响调度时延，更改HZ肯定是有效果的。
但调度时延的不确定性，HZ无能为力。
实时抢占补丁对内核改动还是非常大的，坛子里没什么人讨论这个补丁啊。:-D
这个如果其他进程抢占了cpu， 应该很难保证事件马上会被处理吧。
只能把工作线程的粒度弄小点，然后把这个定时器事件检测整合到事件循环里面去。
回复 2# hmsghnh
谢谢回复！粒度小一些可能会有点效果，但应该不能从根本上解决这个问题吧？如果系统调度过于复杂和频繁，应该还是会出现此类问题的。
处理事件的线程在获取cpu后，占用cpu多长时间后，释放cpu？
还有这个处理事件的线程是sched_FIFO，还是SCHED_RR的？
tick应该设置为1ms吧，linux2.6应该能胜任毫秒级的实时吧 赞同楼上。到了用户态,CPU 啥时给你用就很不好说了。
如果是多核，不妨给这个线程一个独占的核试试看 回复 5# mordorwww
谢谢回复！CPU处理这个线程的时间不会超过4mS，具体操作可精简。线程使用的是sched_FIFO。TICK值更改应该要慎重吧？我也认为，Linux对于处理mS级的实时不应该这么烂。那么，你认为问题的关键是在哪里？
回复 5# mordorwww
谢谢回复！ARM仅仅是一个单核A8，没办法单独用一个核来做这个事情。
我觉很实时的部分，还是放在kernel层比较好， 剩下实时性要求不高的部分，signal user space去做。
本帖最后由 mordorwww 于 2013-06-20 12:07 编辑
先排除其它因素的干扰，系统仅处理这个中断信号，其它网络、其它中断等能关闭就关闭，用户态进程也只做信号处理，看看结果如何
如果这个结果是OK的，再逐步添加关闭的东西
有时中断会让你的时延增加