蜗窝科技

关于级联的中断处理，我认为博文漏掉了一个domain如何衔接的片段。 void gic_handle_irq(struct pt_regs *regs) { struct gic_chip_data *gic = &gic_data[0]; void __iomem *cpu_base = gic_data_cpu_base(gic); irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK); irqnr = irqstat & GICC_IAR_INT_ID_MASK; irqnr = irq_find_mapping(gic->domain, irqnr); handle_IRQ(irqnr, regs); generic_handle_irq(irq) desc->handle_irq(irq, desc); //对于级联，应是gic_handle_cascade_irq() } void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) { //gic_handle_cascade_irq()传递进来的参数是root GIC的级联点的virq号 struct gic_chip_data *chip_data = irq_get_handler_data(irq);-------------（1） struct irq_chip *chip = irq_get_chip(irq); unsigned int cascade_irq, gic_irq; unsigned long status; status = readl_relaxed(gic_data_cpu_base(chip_data) + GIC_CPU_INTACK); //此处居然是次级 GIC的读取操作了 gic_irq = (status & 0x3ff); cascade_irq = irq_find_mapping(chip_data->domain, gic_irq); generic_handle_irq(cascade_irq); desc->handle_irq(irq, desc); } 对于gic_handle_cascade_irq()中的处理，没显式看到domain的转换代码。之前一直卡在这里。 对于（1）代码，才是转换domain的关键；因为在次级GIC初始化的时候，有如下代码： if (parent) { gic_cascade_irq(gic_cnt, irq); if (irq_set_handler_data(irq, &gic_data[gic_nr]) != 0)--------(2) BUG(); irq_set_chained_handler(irq, gic_handle_cascade_irq); } 代码（2）中，是将次级GIC_DATA保存在上级GIC的级联点对应的irq_desc中。以此来保证代码（1）中domain转换。

@schedule：schedule，你是做哪一行的？虽然你说你是菜鸟级别，不过感觉对fs还是比较了解的，你是搞服务器（数据中心、云计算什么的）方向的吗？

@lucky：我定义你说的重要的几个版本就是long term的版本，具体如下： longterm: 3.18.21 longterm: 3.14.52 longterm: 3.12.47 longterm: 3.10.88 longterm: 3.4.108 longterm: 3.2.71 longterm: 2.6.32.67 这些longterm的版本不会增加新的功能，但是会修复各种issue。选定了这些版本之后，可以通过changelog了解各个版本之间的功能的不同，我没有仔细研究这些版本的不同，因此无法给出具体的信息，如果你有兴趣可以去看看，有什么心得可以发布在网站上哦

@linuxer：其实文件系统方面我就是菜鸟级别的。 btrfs更新是很快，但是感觉好多东西都是在模仿ZFS，ZFS 10年前都有商业部署了，btrfs概念炒的比较厉害，但是总是感觉像付不起的阿斗，有那么点不给力。一直以为红帽会在fedora发行版上作为默认的文件系统，结果XFS 突然上位。 我觉得现在想在文件系统做投入，要么搞大（像Global FS），要么搞小（F2FS）。PC或者小型机级别的FS都被云概念炒翻了。当然btrfs很多概念很先进，学习是绝对值得的。

@schedule：原因有几个： 1、我一直对文件系统比较感兴趣，但是之前由于搞嵌入式，因此都是一些小打小闹的文件系统（例如yaffs），一直想了解一个功能比较强大的文件系统的运作机制。 2、有一段时间我很关注内核的更新情况（现在都没有时间去了解了），看到btrfs更新非常频繁，处于活跃期，这时候的模块有很多issue，可参与度比较高 3、我简单的检索了一下资料，似乎btrfs有取代EXT4文件系统的趋势 文件系统模块，schedule有什么推荐？

btrfs 目前看没啥前途啊，linuxer怎么看中了这个模块

@linuxer：您好 我的意思是重要的几个版本。以及它们的关键性的区别

2个NUMA节点node0和node1，node0下面有CPUA、CPU B，node1下面有CPU C、CPU D。 系统启动后，系统默认的workqueue会在A、B、C、D CPU下面分别创建2个线程池，系统还会给node0和node1下面分别创建一个默认的1个线程池。系统有2个默认的workqueue，分别是per-CPU类型的和unbound类型的，对于per-CPU的workqueue会分别在4个CPU下分别挂入一个pool_workqueue，应该是挂入的低优先级的线程池；对于unbound的workqueue会分别在node0和node1的线程池下面各挂入一个pool_workqueue。 --------------------------------------------------------------------------------- 这一段描述还保留了旧的workqueue的影子，CMWQ中的per cpu线程池（两个，优先级不同）是一直存在的，和workqueue的创建没有任何的关系。per cpu的workqueue在创建的时候仅仅是创建pool wq，建立和线程池的关系而已。unbound线程池和workqueue是有关系的，创建了一个有独特属性A的workqueue的时候，往往会创建一个线程池，但是，该线程池和workqueue也是没有一一对应的关系，当创建了另外一个属性A的 unbound workqueue的时候，不会新创建线程池，仅仅是link到之前创建的那个unbound线程池上而已。 另外，假设对于某个线程池有3个线程，且都是idle,现在有4个work，挂入线程池时，现场池会唤醒一个线程执行work0，但是work0在执行过程中阻塞了，现场池会再唤醒一个线程继续执行work1。问题是，这个线程中有几个活动现场，几个空闲线程？ ----------------------------------------------------------------------------------------------- 线程池的策略是只要有一个处于active的worker thread在处理work，它就不会启动新的worker线程。

@lucky：建议到https://www.kernel.org/上去看看各个版本的change log就OK了，太宽泛的问题不是很好回答，抱歉。

@andyshrk：应该是根据其基于的那个HW timer的精度确定的，例如一个32kHz作为输入时钟源的HW timer精度会小于一个13MHz的hw timer，这些hw timer对应的clocksource和clock event的rating应该保持同样的关系