linux内核 smp,linux-kernel – 了解最新(3.0.0及以上版本)Linux内核中CONFIG_SMP,Spinlocks和CONFIG_PREEMPT之间的链接...

a)Linux是否抢先取决于您是否以这种方式配置它

使用CONFIG_PREEMPT.没有默认值.如果你运行make config,你将不得不选择.

b)中断在Linux上嵌套;在处理中断时,其他中断可能会中断.在ARM和许多其他架构上都是如此.它们都在同一个堆栈上.当然,用户空间堆栈不用于中断！

c)如果禁用SMP和抢占,如果它们是常规自旋锁,则代码中的自旋锁将减少为无操作,并且IRQ自旋锁(spin_lock_irqsave / spin_lock_irqrestore)将变为中断禁用/启用.因此,后者仍然是必不可少的;它们可以阻止运行代码的任务与运行代码的中断之间的竞争.

d)“上半部分”传统上是指中断服务程序.驱动程序的上半部分代码由中断运行.下半部分由任务调用(读取或写入数据或其他).中断处理的细节是体系结构特定的.

I most recently worked very closely with Linux interrupts on a particular MIPS architecture. On that particular board,there were 128 interrupt lines maskable via two 64 bit words. The kernel implemented a priority scheme on top of this,so before executing a handler for a given interrupt,the lower ones were masked via updates of those 2×64 bit registers. I implemented a modification so that the interrupt priorities could be set arbitrarily,rather than by hardware position,and dynamically by writing values into a /proc entry. Moreover,I put in a hack whereby a portion of the numeric IRQ priority overlapped with real-time priority of tasks. So RT tasks (i.e. user space threads) assigned to certain range of priority levels were able to implicitly suppress a certain range of interrupts while running. This was very useful in preventing badly-behaved interrupts from interfering with critical tasks (for instance,an interrupt service routine in the IDE driver code used for the compact flash,which executes busy loops due to a badly designed hardware interface,causing flash writes to become the de-facto highest priority activity in the system.) So anyway,IRQ masking behavior isn’t written in stone,if you’re in control of the kernel used by customers.

问题中引用的陈述仅适用于常规自旋锁(spin_lock函数/宏)而不是IRQ自旋锁(spin_lock_irqsave).在单处理器上的可抢占内核中,spin_lock只需要禁用抢占,这足以在spin_unlock之前将所有其他任务保留在内核之外.但spin_lock_irqsave必须禁用中断.