0

I read the book "understanding the Linux kernel". I cannot understand a sentence,that is ,the local CPU must have local interrupts enabled, otherwise kernel preemption is not performed. What is the meaning of this sentence?

2
  • Don't have that book, I would assume its saying that preempt is done when the CPU receives an interrupt—so with them disabled, it won't work. You could help someone with the book to give you a non-guess answer with some more details (e.g., some context from the book and also section or page number where that sentence occurs).
    – derobert
    Jun 14 '16 at 17:16
  • If you want a deeper guess, it implies that pre-emption switching from one process to another requires a timer to work, which requires an interrupt to run.
    – infixed
    Jun 14 '16 at 17:34
1

That sentence from the book is incorrect. Preemption can still happen with IRQs being disabled. Sort of.

Preemption is tricky because it can be triggered in a variety of ways, only one of which is through interrupts. For instance, you could always preempt your code directly by calling schedule() which doesn't care about preemption enabling/disabling or about interrupts. cond_resched() is another function which doesn't care about interrupts being disabled.

So the answer to the question

why local CPU must have interrupts enabled, otherwise kernel preemption is not performed?

It doesn't. Preemption can still happen with interrupts disabled. Asynchronous preemption that can happen at any moment can't happen with interrupts disabled. But preemption caused serially by code that you're executing can still happen. Warnings about this exist in the documentation.

However, it doesn't help the confusion that some of these synchronous code paths, like through preempt_enable(), are refuse to preempt if interrupts are disabled. Other paths like cond_resched(), still allow it. The reasoning is likely because of how explicit the function is. cond_resched() is an explicit preemption request, similar to schedule(). Things like preempt_enable() are less explicit, and could trigger preemption accidentally, so it prevents preemption if interrupts are disabled.

0

If local (context implies "on This CPU") interrupts are forbidden, the (local) CPU will never see an interrupt to trigger possible kernel pre-emption.

1
  • but in function preempt_enable() which includes "if (!current_thread_info->preempt_count && !irqs_disabled()) { current_thread_info->preempt_count = PREEMPT_ACTIVE; schedule(); current_thread_info->preempt_count = 0; }". Why does the if statement chech whether the local interrupt is enabled by !irqs_disabled() Jun 14 '16 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.