说“Linux 内核是抢占式的"是什么意思? [英] What does it mean to say "linux kernel is preemptive"?

问题描述

我读到 Linux 内核是抢占式的，这与大多数 Unix 内核不同.那么，内核具有抢占性究竟意味着什么?

I read that Linux kernel is preemptive, which is different from most Unix kernels. So, what does it really mean for a kernal to be preemptive?

一些类比或例子比纯理论解释更好.

Some analogies or examples would be better than pure theoretical explanation.

先发制人只是多任务处理的一种范式.还有其他类似协作多任务.通过比较它们可以更好地理解.

Preemptive is just one paradigm of multi-tasking. There are others like Cooperative Multi-tasking. A better understanding can be achieved by comparing them.

推荐答案

想象一下抢占式多任务处理的简单视图.我们有两个用户任务，它们都一直在运行，而不使用任何 I/O 或执行内核调用.这两个任务无需执行任何特殊操作即可在多任务操作系统上运行.内核，通常基于定时器中断，简单地决定是时候暂停一个任务让另一个任务运行.有问题的任务完全不知道发生了什么.

Imagine the simple view of preemptive multi-tasking. We have two user tasks, both of which are running all the time without using any I/O or performing kernel calls. Those two tasks don't have to do anything special to be able to run on a multi-tasking operating system. The kernel, typically based on a timer interrupt, simply decides that it's time for one task to pause to let another one run. The task in question is completely unaware that anything happened.

然而，大多数任务偶尔会通过系统调用向内核发出请求.发生这种情况时，存在相同的用户上下文，但 CPU 正在代表该任务运行内核代码.

However, most tasks make occasional requests of the kernel via syscalls. When this happens, the same user context exists, but the CPU is running kernel code on behalf of that task.

旧的 Linux 内核永远不会允许在忙于运行内核代码时抢占任务.(注意 I/O 操作总是自动重新调度.我说的是内核代码有一些 CPU 密集型操作，比如对列表进行排序的情况.)

Older Linux kernels would never allow preemption of a task while it was busy running kernel code. (Note that I/O operations always voluntarily re-schedule. I'm talking about a case where the kernel code has some CPU-intensive operation like sorting a list.)

如果系统允许在运行内核代码时抢占该任务，那么我们就有了所谓的抢占内核".这样的系统不受系统调用期间可能遇到的不可预测的延迟的影响，因此它可能更适合嵌入式或实时任务.

If the system allows that task to be preempted while it is running kernel code, then we have what is called a "preemptive kernel." Such a system is immune to unpredictable delays that can be encountered during syscalls, so it might be better suited for embedded or real-time tasks.

例如，如果在特定 CPU 上有两个任务可用，一个需要 5 毫秒才能完成的系统调用，另一个是需要每 2 毫秒馈送音频管道的 MP3 播放器应用程序，您可能会听到口吃音频.

For example, if on a particular CPU there are two tasks available, and one takes a syscall that takes 5ms to complete, and the other is an MP3 player application that needs to feed the audio pipe every 2ms, you might hear stuttering audio.

反对抢占的论点是，所有可能在任务上下文中调用的内核代码都必须能够在抢占中幸存下来——例如，有很多糟糕的设备驱动程序代码，如果它总是能够完成可能会更好在允许其他任务在该处理器上运行之前的操作.(如今，对于多处理器系统而言，规则而不是例外，所有内核代码都必须是可重入的，因此该论点在今天不再相关.)此外，如果可以通过改进系统调用来实现相同的目标延迟，也许抢占是不必要的.

The argument against preemption is that all kernel code that might be called in task context must be able to survive preemption-- there's a lot of poor device driver code, for example, that might be better off if it's always able to complete an operation before allowing some other task to run on that processor. (With multi-processor systems the rule rather than the exception these days, all kernel code must be re-entrant, so that argument isn't as relevant today.) Additionally, if the same goal could be met by improving the syscalls with bad latency, perhaps preemption is unnecessary.

一个折衷方案是 CONFIG_PREEMPT_VOLUNTARY，它允许在内核内部的某些点进行任务切换，但不是所有地方.如果只有少数几个地方可能会导致内核代码陷入困境，这是一种降低延迟同时保持复杂性可管理的廉价方法.

A compromise is CONFIG_PREEMPT_VOLUNTARY, which allows a task-switch at certain points inside the kernel, but not everywhere. If there are only a small number of places where kernel code might get bogged down, this is a cheap way of reducing latency while keeping the complexity manageable.

这篇关于说“Linux 内核是抢占式的"是什么意思?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！