说"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.

但是，大多数任务偶尔会通过syscalls发出内核请求.发生这种情况时，存在相同的用户上下文，但是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.

反对抢占的论点是，可能在任务上下文中调用的所有内核代码都必须能够幸免于抢占-例如，存在很多不良的设备驱动程序代码，如果始终能够完成，则可能会更好在允许其他任务在该处理器上运行之前的一项操作. (如今，使用多处理器系统作为规则而不是例外，所有内核代码都必须是可重入的，因此该参数在今天已经不那么重要了.)此外，如果可以通过改善syscall来改善不良状况而达到相同的目标.延迟，也许不需要抢占.

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屋！