蜗窝科技

@piter：用户空间的程序（例如irq banlance）可以通过proc文件系统和linux 中断子系统交互IRQ affinity的相关信息： 1、/proc/irq/default_smp_affinity。通过该接口可以访问系统缺省的IRQ affinity。在内核的source code中定义为： cpumask_var_t irq_default_affinity; 在系统初始化的时候，irq_default_affinity被初始化成送达所有CPU（参考early_irq_init函数）。在具体中断描述符初始化的时候，会用irq_default_affinity来初始化desc->irq_data.affinity成员。 需要注意的是：向该接口写入新的缺省IRQ affinity不会影响已经设定的中断描述符，但是新分配的中断描述符的affinity（desc->irq_data.affinity成员）会按照新的default irq affinity值进行初始化。 2、/proc/irq/<irq>/。linux kernel会为每一个IRQ number建立一个目录，保存该IRQ相关的信息 3、/proc/irq/<irq>/smp_affinity。通过该接口可以访问具体某个IRQ number的IRQ affinity（desc->irq_data.affinity成员）。初始化的时候，该值被设定为系统缺省的IRQ affinity（irq_default_affinity），在系统运行过程中，根据实际系统中断负荷和irq balancing的策略，有可能会修改该值。 4、/proc/irq/<irq>/affinity_hint。通过该接口可以读取（read only）具体某个IRQ number的affinity hint（desc->affinity_hint成员）。 底层的driver可以通过irq_set_affinity_hint接口来设定它期望的affinity值，当然，这只是给用户空间一个提示，运行于用户空间的irq affinity daemon进程会根据这个值进行IRQ affinity的设定 5、/proc/irq/<irq>/smp_affinity_list。这个接口是和/proc/irq/<irq>/smp_affinity接口是一样的，只不过表述形式不一样而已。/proc/irq/<irq>/smp_affinity是用cpu mask的形式给出的，但是当cpu的数目比较大的时候，调整affinity变得不那么方便了，因此，linux kernel增加了smp_affinity_list的接口，这个接口的输出是用ascii的形式输出，我们还是举例子吧： 如果一个IRQ被允许送达cpu3和cpu6，那么读取smp_affinity_list将返回3，6 如果一个IRQ被允许送达所有的cpu（0～7），那么读取smp_affinity_list将返回0-7 .......

@linuxer：irq banlance daemon!! 竟然有這種東西~~ 請問一下，知道他在哪個地方有真正設定到irq 分配給哪個cpu 嗎~? 感謝~

@RobinHsiang：主要是让宏定义规范一些，我也没想那么多，看别人用自己就用了。呵呵~~

@RobinHsiang：呵呵，刚刚搜索到答案了，以前没多想这问题。 Wowo真是深受linux内核的熏陶啊~~~

#define ASSERT() \ do { \ PRINT("ASSERT: %s %s %d", \ __FILE__, __FUNCTION__, __LINE__); \ while (1); \ } while (0) 有时候不能用goto可以这样使用do{} while(0)，但内核中定义宏很多时候也用do{} while(0)，这样主要是为了编译器对宏的展开么？

@printk：您现在的工作地点在哪？我以后也想进类似企业，谢谢

很好很强大！方便我调试bug了～

@tastier：你那个是属于低功耗的，低性能的，基于X86架构的片子，定位应该属于中低端市场把。。。。单纯比性能没什么意义，在车载方面，不需要太花哨的性能值，稳定与低功耗在短时间内，还是一直在统领车载市场的。毕竟安卓系统进入车载后，如果发生类似于安卓手机这种越用越卡，经常死机的情况的话，那就太危险了。 我们单位是一个老牌车载导航日企，名字不方便透露，抱歉！

@piter，由于有回复限制，因此我copy了一份您的问题： 想請教一下，看到你說的這個gic_dist_init只會讓該中斷對應到一個cpu。然後我就去追當我們註冊irq時的這個function:request_threaded_irq，發現他最後也是call 這個gic_dist_init這個:: request_threaded_irq ->__setup_irq -> setup_affinity -> chip->irq_set_affinity (.irq_set_affinity = gic_set_affinity, drivers/irqchip/irq-gic.c) 這樣不是代表，當我們用request_threaded_irq註冊interrupt 時候，該interrupt 只會給特定的cpu 嗎(變成大部分都只有cpu0)? 這樣感覺跟以往的認知不一樣。比如說以往會有個觀念是說若cpu0 正在處理interrupt0 這時候若有interrupt1 進來時，cpu1會去處理interrupt 1。感覺若照程式這樣看來，會變成同一時間只能有單一中斷被響應...。 請問您有什麼看法，感謝 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 我觉得这是一个策略和机制的问题。对于内核中的中断子系统，当然只是负责提供机制，例如提供set affinity的策略。到底SPI的中断由哪一个cpu处理是一个策略问题。可能是永远的将某个外设（例如ethernet）的中断送达cpu0（配合的系统策略是：在该cpu上启动若干的线程来处理来自网络的请求），也可能是平均分配外设的中断，象你说的那样，一会cpu0处理，一会儿cpu1处理。 但无论如何，内核无法确定策略，因此，在系统初始化的时候，总是先初始化成一种形态，后续应该会有一些其他的软件模块（irq banlance daemon）会根据irq的负荷来控制irq affinity的。

@buyit：从timer的角度看应用程序和驱动，其实只是有两种，一种是有real time需求的，一种是没有。没有hrtimer的支持，那么timer的精度受限于tick。 假设hz=100，也就是说tick的精度是10ms，无论是驱动（调用timer接口）还是应用程序（posix clock and timer接口），设定10ms以下的精度，例如2ms，那么实际上这个timer由于精度不够，不可能在2ms秒后触发，而是在10ms后触发。如果支持hrtimer，那么2ms后即可以触发，并启动处理过程，当然，对于用户空间的程序还存在调度问题，这是另外一个话题了。 我觉得hrtimer是不是为了服务器级别的驱动和应用程序无关，只是和real time application相关，而这样的应用是不分服务器或者嵌入式平台的