操作系统内核和主内存中的进程

Question

继续我在操作系统开发研究方面的努力，我已经构建了一个几乎完整的图片。还有一件事我不知道。

根据我的理解，这是基本的启动过程：

1）BIOS / Bootloader执行必要的检查，初始化所有内容。

2）内核被加载到RAM中。

3）内核执行初始化并开始调度任务。

4）加载任务时，会为其提供一个虚拟地址空间。包括.text，.data，.bss，堆和堆栈。此任务“维护”自己的堆栈指针，指向其自己的“虚拟”堆栈。

5）上下文切换只是将寄存器文件（所有CPU寄存器），堆栈指针和程序计数器推入某个内核数据结构，并加载另一个属于另一个进程的集合。

在这个抽象中，内核是一个“母”过程，其中所有其他进程都是托管的。我试图在下图中表达我最好的理解：

问题是，首先这个简单的模型是否正确？

其次，可执行程序如何识别其虚拟堆栈？是OS作业来计算虚拟堆栈指针并将其放在相关的CPU寄存器中吗？堆栈簿记的其余部分是由CPU弹出和推送命令完成的吗？

内核本身是否有自己的主堆栈和堆？

感谢。

Answer 1

  

问题是，首先这个简单的模型是否正确？

您的模型非常简化但基本上是正确的 - 请注意，模型的最后两部分并不真正被认为是引导过程的一部分，并且内核不是一个过程。将它可视化为一个可能很有用，但它不适合过程的定义，并且它不像一个过程。

  

其次，可执行程序如何识别其虚拟堆栈？   是计算虚拟堆栈指针并放置它的OS作业   在相关的CPU寄存器中？剩下的是堆栈簿记   由CPU弹出和推送命令完成？

可执行C程序不必“了解其虚拟堆栈”。当C程序编译成可执行文件时，通常会相对于堆栈指针引用局部变量 - 例如，[ebp - 4]。

当Linux加载新程序以执行时，它使用start_thread宏（从load_elf_binary调用）来初始化CPU的寄存器。该宏包含以下行：

regs->esp = new_esp;   

将CPU的堆栈指针寄存器初始化为OS已分配给线程堆栈的虚拟地址。

正如您所说，加载堆栈指针后，pop和push等汇编命令将更改其值。操作系统负责确保存在与虚拟堆栈地址对应的物理页面 - 在使用大量堆栈内存的程序中，随着程序继续执行，物理页面的数量将增加。使用ulimit -a命令可以找到每个进程的限制（在我的机器上，最大堆栈大小为8MB，或2KB页面）。

  

内核本身是否有自己的主堆栈和堆？

这是将内核可视化为进程可能会变得混乱的地方。首先，Linux中的线程具有用户堆栈和内核堆栈。它们基本相同，仅在保护和位置上有所不同（在内核模式下执行时使用内核堆栈，在用户模式下执行时使用用户堆栈）。

内核本身没有自己的堆栈。内核代码总是在某个线程的上下文中执行，每个线程都有自己的固定大小（通常是8KB）内核堆栈。当线程从用户模式移动到内核模式时，CPU的堆栈指针会相应更新。因此，当内核代码使用局部变量时，它们存储在它们正在执行的线程的内核堆栈中。

在系统启动期间，start_kernel函数初始化内核init线程，然后创建其他内核线程并开始初始化用户程序。因此，在系统启动后，CPU的堆栈指针将被初始化为指向init的内核堆栈。

就堆而言，您可以使用kmalloc在内核中动态分配内存，这将尝试在内存中查找空闲页面 - 其内部实现使用get_zeroed_page。

Answer 2

您忘了一点：Virtual memory 强制执行，通常称为MMU（内存管理单元）。 MMU将虚拟地址转换为物理地址。

内核通常将特定进程的页表的基址地址加载到MMU中的寄存器中。这就是任务 - 将虚拟内存空间从一个进程切换到另一个进程。在x86上，该寄存器为CR3。

虚拟内存保护进程＆＃39;彼此记忆犹新。进程A的RAM根本没有映射到进程B中。（例如shared libraries除外，其中相同的代码存储器被映射到多个进程，以节省内存）。

虚拟内存还可以保护内核内存空间免受用户模式进程的影响。设置覆盖内核地址空间的页面上的属性，以便当处理器在用户模式下运行时，不允许在那里执行。

请注意，虽然内核可能拥有自己的线程，而这些线程完全在内核空间中运行，但内核不应该被认为是一个＆＃34;一个母进程＆＃34;独立于用户模式程序运行。内核基本上是＆＃34;另一半＆＃34;您的用户模式程序！无论何时发出system call，CPU都会自动转换到内核模式，并开始在内核指定的预定义位置执行。然后，内核系统调用处理程序代表您执行，在您的进程的内核模式上下文中。计算内核处理您的请求所花费的时间，并且＆＃ 34;收取＆＃34;你的过程。

Answer 3

在与流程和线程的关系环境中思考内核的有用方法

您提供的模型非常简化，但一般都是正确的。 同时关于内核的思考方式是关于＆＃34;母亲过程＆＃34;不是最好的，但它仍然有一定道理。 我想提出另外两个更好的模型。

1. 尝试将内核视为特殊类型的共享库。 像共享库一样，内核在不同进程之间共享。 系统调用的执行方式与概念上类似于来自共享库的例程调用。 在这两种情况下，在通话结束后，您执行＆＃34; foreign＆＃34;代码但在上下文中是您的本机进程。 在这两种情况下，您的代码都会继续执行基于堆栈的计算。 另请注意，在这两种情况下都要调用＆＃34; foreign＆＃34;代码导致阻止执行你的＆＃34; native＆＃34;码。 从调用返回后，执行从代码的相同点开始继续，并且执行调用的堆栈状态相同。 但是为什么我们认为内核是一个特殊的＆＃34;那种共享库？这是因为：

   一个。内核是一个＆＃34;库＆＃34;由系统中的每个进程共享。

   湾内核是一个＆＃34;库＆＃34;它不仅共享代码段，还共享数据段。

   ℃。内核是一个受到特别保护的＆＃34;库＆＃34;。您的流程无法直接访问内核代码和数据。相反，它被迫通过特殊的＃34;呼叫门调用内核控制方式。

   d。在系统调用的情况下，您的应用程序将在几乎连续的堆栈上执行。但实际上，这个堆栈将由两个独立的部分组成。一部分用于用户模式，第二部分将在进入内核时逻辑连接到用户模式堆栈的顶部，并在退出时脱离。

2. 在计算机中考虑计算组织的另一种有用的方法是将其视为虚拟网络＆＃34;没有虚拟内存支持的计算机。 您可以将进程视为虚拟多处理器计算机，该计算机只执行一个可访问所有内存的程序。 在这个模型中，每个＆＃34;虚拟＆＃34;处理器将由执行线程表示。 就像你可以拥有一台带有多个处理器（或多核处理器）的计算机一样，你可以在你的进程中拥有多个当前运行的线程。 与您的计算机一样，所有处理器都具有对物理内存池的共享访问权限，进程的所有线程共享对同一虚拟地址空间的访问权限。 就像单独的计算机在物理上彼此隔离一样，您的进程也在逻辑上彼此隔离。 在该模型中，内核由具有直接连接到具有星形拓扑的网络中的每个计算机的服务器表示。 与网络服务器类似，内核有两个主要目的：

   一个。服务器组装单个网络中的所有计算机。 类似地，内核提供了进程间通信和同步的手段。内核作为中间的人工作，它调解整个通信过程（传输数据，路由消息和请求等）。

   湾就像服务器为每台连接的计算机提供一些服务一样，内核为这些进程提供了一组服务。例如，像网络文件服务器允许计算机读取和写入位于共享存储上的文件，您的内核允许进程执行相同的操作，但使用本地存储。

请注意，在客户端 - 服务器通信范例之后，客户端（进程）是网络中唯一的活动参与者。他们向服务器和彼此之间发出请求。服务器又是系统的反应部分，它从不启动通信。相反，它只回复传入的请求。 该模型反映了系统各部分之间的资源共享/隔离关系以及内核和进程之间通信的客户端 - 服务器性质。

如何执行堆栈管理，以及在该过程中扮演内核的角色

当新进程启动时，内核使用来自可执行映像的提示，确定将为进程的初始线程的用户模式堆栈保留的虚拟地址空间的位置和数量。 做出这个决定后，内核会设置处理器寄存器集的初始值，这些值将在执行开始后由进程的主线程使用。 此设置包括设置堆栈指针的初始值。 在实际开始执行流程之后，流程本身就成为堆栈指针的负责人。 更有趣的是，进程负责初始化由它创建的每个新线程的堆栈指针。 但请注意，内核内核负责为系统中的每个线程分配和管理内核模式堆栈。 另请注意，内核对于堆栈的物理内存分配是可以承担的，并且通常使用页面错误作为提示，根据需要懒惰地执行此作业。 运行线程的堆栈指针由线程本身管理。在大多数情况下，堆栈指针管理由编译器在构建可执行映像时执行。编译器通常通过添加和跟踪与堆栈相关的所有指令来跟踪堆栈指针值并保持其一致性。 此类指示不仅限于＆＃34; push＆＃34;和＆＃34; pop＆＃34;。有许多CPU指令会影响堆栈，例如＆＃34; call＆＃34;和＆＃34; ret＆＃34;，＆＃34; sub ESP＆＃34;和＃34;添加ESP＆＃34;等 正如您所看到的，堆栈指针管理的实际策略大多是静态的，并且在流程执行之前就已知。 有时，程序具有执行特殊堆栈管理的逻辑的特殊部分。 例如，协同程序的实现或C中的长跳跃。 事实上，如果你愿意，你可以用程序中的堆栈指针做任何你想做的事。

内核堆栈架构

我了解这个问题的三种方法：

1. 系统中每个线程分离内核堆栈。这是大多数知名操作系统采用的方法，基于单片内核，包括Windows，Linux，Unix，MacOS。 虽然这种方法导致内存方面的显着开销并且恶化缓存利用率，但它改善了内核的抢占，这对于具有长时间运行的系统调用的单片内核尤其在多处理器环境中是至关重要的。 实际上，很久以前Linux只有一个共享内核堆栈，整个内核都被Big Kernel Lock所覆盖，它只能通过一个线程限制线程数量，这些线程可以同时执行系统调用。 但是Linux内核开发人员已经很快意识到阻止执行一个想知道例如其PID的进程，因为另一个进程已经开始通过非常慢的网络发送大数据包是完全没有效率的。

2. 一个共享内核堆栈。 微内核的权衡是非常不同的。 具有短系统调用的小内核允许微内核设计者坚持使用单内核堆栈进行设计。 在证明所有系统调用都非常短的情况下，它们可以从提高的缓存利用率和更小的内存开销中受益，但仍然可以保持良好的系统响应能力。

3. 系统中每个处理器的内核堆栈。 即使在微内核操作系统中，一个共享内核堆栈也会严重影响多处理器环境中整个操作系统的可扩展性。 因此，设计人员经常遵循上述两种方法之间的折衷方法，并在系统中为每个处理器（处理器内核）保留一个内核堆栈。 在这种情况下，它们受益于良好的缓存利用率和较小的内存开销，这比每个线程的堆栈方法要好得多，并且比单个共享堆栈方法稍微恶化。 同时，他们也受益于系统良好的可扩展性和响应能力。

感谢。