task 切换过程（线程/进程）

First of all, operating system brings outgoing thread in a kernel mode if it not already there, because thread switch can be performed only between threads, which run in kernel mode. Then 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 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 the 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 the most cases the working set used by the outgoing thread will differ significantly from working set which is used by incoming thread. As a result, 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. 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 TLB. The sad story is that entire TLB is flushed, even if new thread actually need to load only few new entries. As a result, new thread will start its time quantum with 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.

 

 

https://stackoverflow.com/questions/5440128/thread-context-switch-vs-process-context-switch