Linux内核:schedule()在什么进程中运行?

发布于 2024-12-19 10:26:50 字数 210 浏览 2 评论 0原文

当您在进程 X 中调用诸如 fork 之类的系统调用时,内核被认为是在进程上下文中执行。那么,fork可以说是运行在进程X中,对吧?

但是,如果在同一进程中调用 schedule() (并且它不是系统调用),您会说它是作为 X 的一部分运行吗?或者它在交换器进程中运行?或者考虑到内核的整体性,这听起来很荒谬吗?

When you call a system call such as fork in process X, the kernel is said to be executing in process context. So, fork can be said to be running in process X, right?

But if schedule() is called (and it isn't a sys call) in the same process, would you say that it is running as part of X? Or does it runs in the swapper process? Or does it sound absurd, taking into account the monolithic nature of the kernel?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

桜花祭 2024-12-26 10:26:50

schedule() 始终在进程上下文中运行。它的特殊之处在于它可以更改当前的进程上下文 - 但它始终具有进程上下文。在调用 context_switch() 之前,它在要换出的进程的上下文中运行,并且在调用之后在换入的进程中运行。Linux

内核没有专用的“swapper”任务(有一个空闲任务,如果没有其他任务可以运行,则该任务始终可以运行)。

schedule() is always running in process context. The special part about it is that it can change which process context is current - but it does always have a process context. Prior to the call to context_switch() it runs in the context of the process to be swapped out, and after it runs in the process swapped in.

The Linux kernel does not have a dedicated "swapper" task (there is an idle task, which is always runnable in case nothing else is eligible to run).

叹梦 2024-12-26 10:26:50

这实际上取决于 schedule() 调用的位置; schedule() 可以从进程上下文或工作队列中调用。工作队列是内核调度的线程:

# ps auxw | grep worker
root      1378  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/1:0]
root      1382  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/2:0]
root      1384  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/3:1]
...

[..] 表示进程不在用户空间中执行。

worker_thread() 函数在处理工作项之后但重新开始之前调用 schedule()

schedule() 也可以代表进程调用,可以通过驱动程序、信号处理代码、文件系统内部结构或无数其他选项来调用。

It really depends upon where the schedule() call is made from; schedule() can be called both from process context or from a work queue. The work queues are kernel-scheduled threads:

# ps auxw | grep worker
root      1378  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/1:0]
root      1382  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/2:0]
root      1384  0.0  0.0      0     0 ?        S    20:45   0:00 [kworker/3:1]
...

The [..] signifies that the processes do not execute in userspace.

The worker_thread() function calls schedule() after handling a work item but before starting all over again.

schedule() can also be called on behalf of a process, either by a driver or by signal handling code, or filesystem internals, or myriad other options.

月光色 2024-12-26 10:26:50

调度程序负责所有进程,因此不在一个进程内运行。

当然,当例如一个进程由于时钟中断而被调度时,某些进程正在运行(稍后,另一个进程被调度)。

您无法将所有内核视为正在运行的进程(只有系统调用才是)。

The scheduler take care of all processes, so does not run inside one process.

Of course, when e.g. a process is scheduled out because of a clock interrupt, some process was running (and later, another one is scheduled).

You cannot view all the kernel as running for processes (only system calls are).

生来就爱笑 2024-12-26 10:26:50

问:那么,fork 可以说是运行在进程 X 中,对吗?

答:是的,绝对如此。进程请求“fork”的系统调用发生在用户空间中。使系统调用从用户空间转换到内核空间的行为。系统调用的实现可能涉及许多单独的步骤。有些可能发生在用户空间;其他步骤发生在内核空间中。

问:...考虑到内核的整体性?

答:“用户空间”与“内核空间”的问题与内核是“整体”、“微内核”还是其他完全无关。

Q: So, fork can be said to be running in process X, right?

A: Yes, absolutely. The system call by which a process REQUESTS to "fork" occurs in user space. The act of making the system call TRANSITIONS from user space to kernel space. The IMPLEMENTATION of the system call may involve many separate steps. Some may occur in user space; other steps occur in kernel space.

Q: ...taking into account the monolithic nature of the kernel ?

A: The issue of "user space" vs "kernel space" has absolutely NOTHING to do with whether the kernel happens to be "monolithic", a "microkernel" or something else entirely.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文