线程上下文切换 Vs.进程上下文切换
谁能告诉我在这两种情况下到底做了什么？他们每个人的主要成本是多少？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
谁能告诉我在这两种情况下到底做了什么？他们每个人的主要成本是多少？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（10）
线程切换和进程切换之间的主要区别在于，在线程切换期间，虚拟内存空间保持不变，而在进程切换期间则不然。
两种类型都涉及将控制权移交给操作系统内核以执行上下文切换。切入和切出操作系统内核的过程以及切出寄存器的成本是执行上下文切换的最大固定成本。
更模糊的成本是上下文切换会扰乱处理器的缓存机制。基本上，当上下文切换时，处理器在其缓存中“记住”的所有内存地址实际上都变得无用。这里的一个很大的区别是，当您更改虚拟内存空间时，处理器的转换后备缓冲区 (TLB) 或等效内容会被刷新，从而使内存访问在一段时间内变得更加昂贵。在线程切换期间不会发生这种情况。
The main distinction between a thread switch and a process switch is that during a thread switch, the virtual memory space remains the same, while it does not during a process switch.
Both types involve handing control over to the operating system kernel to perform the context switch. The process of switching in and out of the OS kernel along with the cost of switching out the registers is the largest fixed cost of performing a context switch.
A more fuzzy cost is that a context switch messes with the processors cacheing mechanisms. Basically, when you context switch, all of the memory addresses that the processor "remembers" in its cache effectively become useless. The one big distinction here is that when you change virtual memory spaces, the processor's Translation Lookaside Buffer (TLB) or equivalent gets flushed making memory accesses much more expensive for a while. This does not happen during a thread switch.
进程上下文切换涉及内存地址空间的切换。这包括内存地址、映射、页表和内核资源——这是一个相对昂贵的操作。在某些体系结构上，它甚至意味着刷新不可跨地址空间共享的各种处理器缓存。例如，x86 必须刷新 TLB，而某些 ARM 处理器必须刷新整个 L1 缓存！
线程切换是同一进程中从一个线程到另一个线程的上下文切换（跨进程从一个线程切换到另一个线程只是进程切换）。切换处理器状态（例如程序计数器和寄存器内容）通常非常高效。
Process context switching involves switching the memory address space. This includes memory addresses, mappings, page tables, and kernel resources—a relatively expensive operation. On some architectures, it even means flushing various processor caches that aren't sharable across address spaces. For example, x86 has to flush the TLB and some ARM processors have to flush the entirety of the L1 cache!
Thread switching is context switching from one thread to another in the same process (switching from thread to thread across processes is just process switching).Switching processor state (such as the program counter and register contents) is generally very efficient.
首先，如果传出线程尚不存在，操作系统会将传出线程引入内核模式，因为线程切换只能在运行于内核模式的线程之间执行。然后调用调度程序来决定将执行切换的线程。做出决定后，内核将位于CPU（CPU寄存器）中的部分线程上下文保存到内存中的专用位置（通常位于传出线程的内核堆栈的顶部）。然后内核执行从传出线程的内核堆栈到传入线程的内核堆栈的切换。之后，内核将先前存储的传入线程的上下文从内存加载到 CPU 寄存器中。最后将控制权返回到用户模式，但处于新线程的用户模式。
当操作系统确定传入线程在另一个进程中运行时，内核会执行一个额外步骤：设置新的活动虚拟地址空间。
这两种情况的主要成本都与缓存污染有关。在大多数情况下，传出线程使用的工作集与传入线程使用的工作集有很大不同。因此，传入线程将在大量缓存未命中的情况下开始其生命周期，从而从缓存中刷新旧的无用数据并从内存中加载新数据。 TLB（Translation Look Aside Buffer，位于CPU上）也是如此。在重置虚拟地址空间（线程在不同进程中运行）的情况下，惩罚会更严重，因为重置虚拟地址空间会导致整个 TLB 的刷新，即使新线程实际上需要仅加载少量新条目。因此，新线程将在大量 TLB 未命中和频繁页面遍历的情况下开始其时间量程。线程切换的直接成本也不容忽视（从约 250 个周期到高达约 1500-2000 个周期），并且取决于 CPU 复杂性、两个线程的状态以及它们实际使用的寄存器组。
PS：关于上下文切换开销的好文章： http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
First of all, operating system brings outgoing thread in a kernel mode if it is not already there, because thread switch can be performed only between threads, that runs in kernel mode. Then the scheduler is invoked to make a decision about thread to which will be performed switching. After decision is made, kernel saves part of the thread context that is located in CPU (CPU registers) into the dedicated place in memory (frequently on the top of the kernel stack of outgoing thread). Then the kernel performs switch from kernel stack of outgoing thread on to kernel stack of the incoming thread. After that, kernel loads previously stored context of incoming thread from memory into CPU registers. And finally returns control back into user mode, but in user mode of the new thread.
In the case when OS has determined that incoming thread runs in another process, kernel performs one additional step: sets new active virtual address space.
The main cost in both scenarios is related to a cache pollution. In most cases, the working set used by the outgoing thread will differ significantly from working set which is used by the incoming thread. As a result, the incoming thread will start its life with avalanche of cache misses, thus flushing old and useless data from the caches and loading the new data from memory. The same is true for TLB (Translation Look Aside Buffer, which is on the CPU). In the case of reset of virtual address space (threads run in different processes) the penalty is even worse, because reset of virtual address space leads to the flushing of the entire TLB, even if new thread actually needs to load only few new entries. As a result, the new thread will start its time quantum with lots TLB misses and frequent page walking. Direct cost of threads switch is also not negligible (from ~250 and up to ~1500-2000 cycles) and depends on the CPU complexity, states of both threads and sets of registers which they actually use.
P.S.: Good post about context switch overhead: http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
在线程上下文切换中，虚拟内存空间保持不变，而在进程上下文切换中则不然。此外，进程上下文切换比线程上下文切换成本更高。
In Thread Context Switching, the virtual memory space remains the same while it is not in the case of Process Context Switch. Also, Process Context Switch is costlier than Thread Context Switch.
我认为主要区别在于调用 switch_mm() 时，它处理新旧任务的内存描述符。对于线程来说，虚拟内存地址空间是不变的（线程共享虚拟内存），因此只需要做很少的事情，因此成本也较低。
I think main difference is when calling
switch_mm()which handles memory descriptors of old and new task. In the case of threads, the virtual memory address space is unchanged (threads share virtual memory), so very little has to be done, and therefore less costly.虽然线程上下文切换需要更改执行上下文（寄存器、堆栈指针、程序计数器），但它们不需要像进程上下文切换那样更改地址空间。当您切换地址空间、更多内存访问（分页、分段等）时会产生额外成本，并且在进入或退出新进程时必须刷新 TLB...
Though thread context switching needs to change the execution context (registers, stack pointers, program counters), they don't need to change address space as processes context switches do. There's an additional cost when you switch address space, more memory access (paging, segmentation, etc) and you have to flush TLB when entering or exiting a new process...
要知道，调度器其实就是线程之间的调度。而对于多线程的进程来说，单核机器一次只能运行一个线程。（参考这个：https://cseweb.ucsd.edu/classes/sp16/cse120-a/applications/ln/lecture5 .html）
因此您可以暗示进程切换实际上是从processA中的“x”线程切换到processB中的“y”线程。
另外，对于线程切换，我们指的是单个进程内线程之间的切换。
经过比较可以发现，要执行进程切换，就必须处理进程包含、线程排除的属性。将其保存在某个地方以便稍后恢复。
You should know that scheduler is actually schedule among threads.And for a process having multiple threads, only a single thread can run at a time for a single-core machine.(Refer this :https://cseweb.ucsd.edu/classes/sp16/cse120-a/applications/ln/lecture5.html)
So you can imply that the process switch is actually switch from 'x' thread in processA to 'y' thread in processB.
Also, for thread switch , we refer to the switch among threads within a single process.
After comparison, you can find that to execute process switch, you have to deal with the attribute which is included in process and excluded by threads. Save it somewhere to restore later.
简而言之，线程上下文切换不会分配一组全新的内存和 pid，它使用与父进程相同的内存和 pid，因为它在同一进程中运行。一个进程会产生一个新进程，从而分配新的 mem 和 pid。
还有更多的事情。他们已经写了这方面的书。
至于成本，进程上下文切换>>>线程，因为您必须重置所有堆栈计数器等。
In short, the thread context switch does not assign a brand new set of memory and pid, it uses the same as the parent since it is running within the same process. A process one spawns a new process and thus assigns new mem and pid.
There is a loooooot more to it. They have written books on it.
As for cost, a process context switch >>>> thread as you have to reset all of the stack counters etc.
假设操作系统运行的 CPU 附加了一些高延迟设备，
则在高延迟设备响应时运行进程地址空间的另一个线程是有意义的。
但是，如果高延迟设备的响应速度快于为新进程设置表+虚拟内存到物理内存的转换所需的时间，那么交换机是否必要就值得怀疑了。
此外，热缓存（运行进程/线程所需的数据可以在更短的时间内到达）是更好的选择。
Assuming that The CPU the OS runs has got Some High Latency Devices Attached,
It makes sense to run another thread Of the Process's Address Space, while the high latency device responds back.
But, if the High Latency Device is responding faster than the time to need do set up of table + translation of Virtual To Physical memories for a NEW Process, then it is questionable if a switch is essential at all.
Also, HOT cache(data needed for running the process/thread is reachable in less time) is better choice.