关抢占 自旋锁_为什么禁用中断会禁用内核抢占以及自旋锁如何禁用抢占

I am reading Linux Kernel Development recently, and I have a few questions related to disabling preemption.

In the "Interrupt Control" section of chapter 7, it says:

Moreover, disabling interrupts also disables kernel preemption.

I also read from the book that kernel preemption can occur in the follow cases:

When an interrupt handler exits, before returning to kernel-space.

When kernel code becomes preemptible again.

If a task in the kernel explicitly calls schedule()

If a task in ther kernel blocks (which results in a call to schedule())

But I can't relate disabling interrupts with these cases.

As far as I know, a spinlock would disable preemption with the preempt_disable() function.

On a single core machine a spinlock is simply a "disable interrupts" or "raise IRQL" which prevents thread scheduling completely.

Does preempt_disable() disable preemption by disabling interrupts?

解决方案

I am not a scheduler guru, but I would like to explain how I see it.

Here are several things.

preempt_disable() doesn't disable IRQ. It just increases a thread_info->preempt_count variable.

Disabling interrupts also disables preemption because scheduler isn't working after that - but only on a single-CPU machine. On the SMP it isn't enough because when you close the interrupts on one CPU the other / others still does / do something asynchronously.

The Big Lock (means - closing all interrupts on all CPUs) is slowing the system down dramatically - so it is why it not anymore in use. This is also the reason why preempt_disable() doesn't close the IRQ.

You can see what is preempt_disable(). Try this:

1. Get a spinlock.

2. Call schedule()

In the dmesg you will see something like "BUG: scheduling while atomic". This happens when scheduler detects that your process in atomic (not preemptive) context but it schedules itself.

Good luck.