CPU context switches often said what does this mean? (on)
https://www.jianshu.com/p/4393a4537eca
Ni Pengfei learning linux teacher performance optimization practice notes, a lot of the text contents of the document material from the teacher, if you like your two-dimensional code at the end of the venue and the text in the screenshot support teacher courses:
Sometimes watching resource utilization of the system, we will find, use the value of the cpu but not to engage in sys value is particularly high, while the load will be higher, then we will be more confused, obviously I program with very little cpu ah, Why load is particularly high? Ah reason is that the context switch.
As we all know, Linux is a multitasking operating system, it supports much larger than the CPU number of tasks running at the same time, of course, these tasks are not actually in operation at the same time, but rather the system in a very short period of time, We will turn their assigned CPU, causing the illusion of many tasks running simultaneously.
Before each task runs, CPU needs to know where to load the task, but also began to run where, say, need to help him set up the system in advanceCPU寄存器和程序计数器(Program Counter,PC)
CPU registers, a small built-in CPU capacity but fast memory. Program counter is used to position the CPU executing stored instructions, or the location of the next instruction to be executed. They are CPU before running any task, you must rely on the environment, it is also called the CPU context.
CPU context to know what happened, I think you are very easy to understand CPU上下文切换. Context switching CPU, CPU context is saved first before a task (i.e. CPU registers and program counter), and then load the new task context, to these registers and program counter, and finally jump to a new program counter refers to position, run a new task.
And preserved context, will be stored in the system kernel, and then re-load came when the task is scheduled for execution. This would ensure that the original task of the state is not affected, so the task still looks continuous operation.
I guess some people will certainly say, CPU context switching is nothing more than updated CPU registers thing, but these registers itself to run the task quickly designed, why would it affect the CPU performance of the system?
Before answering this question, I do not know you ever wondered, what operating system management of these "tasks" in the end what is it?
Perhaps you will say, the task is a process, thread or task is, is the process and thread are the most common tasks, but in addition, there is no other task?
Do not forget, the hardware trigger signal, will cause an interrupt handler is called, which is a common task.
So, depending on the task, context switching the CPU can be divided into several different common, that is 进程上下文切换, 线程上下文切换as well 中断上下文切换.
Here we look at how to understand these unreasonable context switching, and why they cause problems related to CPU performance.
Process context switch
Linux accordance with privilege level, the process of running space into kernel space and user space, corresponding to the figure below. CPU privilege level Ring0 and Ring3.
- Kernel space (Ring 0) has the highest authority, direct access to all resources
- User space (Ring 3) only have access to limited resources, can not directly access memory and other hardware devices, must fall into the kernel through system calls, you can visit these privileged resources.
From another perspective, that is to say, a process which can run in user space, and can run in kernel space. Processes running in user space, the process is called user mode, and kernel space into time, known as the kernel mode processes.
The transition from user mode to kernel mode, need to 系统调用be done, such as when we see the contents of the file, you need to call several times to complete the system: first call open () to open the file, and then call read () reads the contents of the file, and call to write () to write the contents of the standard output, and finally call the close () close the file.
Then, the system calls the process has CPU context switching it did not happen? The answer is yes.
CPU registers the original instruction position of the user state, need to be saved. Next, in order to perform the code kernel mode, the CPU registers need to be updated to the new location of kernel mode instruction. And finally jump to the kernel mode running kernel tasks.
And after the end of a system call, CPU registers need to restore previously saved user mode, and then switch to the user space, continue to run the process, the system calls a process, in fact, there have been two CPU context switching.
However, it should be noted that the system calls the process, and does not involve virtual memory resources processes such as user mode, it will not switch routine. We usually refer to this process with context switching is not the same.
- Process context switch means to switch from one process to another process to run.
- The system calls the process has been running in the same process.
系统调用过程通常称为特权模式切换So 而不是上下文切换, . But in fact the process of system calls, context switching CPU or unavoidable.
Then, a process context switch calls with the system, what difference does it make?
First, you need to know that the process is managed and scheduled by the kernel, the process of switching only occurs in kernel mode. Therefore, the context of the process not only includes virtual memory, stack. User space resource global variables, further comprising a kernel space kernel stack state, registers, etc.
Thus, context switching process on more than one step system call: before saving the current process status and CPU core registers need to first process the saved virtual memory, stack, etc.; and the loading process of the next kernel mode , users also need to stack virtual memory and refresh the new process.
As shown below, the context save and context restore process, are not 免费的required to be completed to allow the kernel on the CPU.
According to the test report Tsuna, each context switch requires tens of nanoseconds to microseconds of CPU time. This time is considerable, especially in the case of a process context switch more frequently, it is easy to cause the CPU to spend too much time on saving and restoring registers, the kernel stack, and virtual memory and other resources, thereby greatly reducing the real time running processes. It is also an important factor leading to the increase in the average load of the mentioned article.
In addition, we know, Linux by TLB (Translation Lookaside Buffer) to manage virtual memory mapping to physical memory. When the updated virtual memory, TLB also need to refresh the memory of the visit will also slow down. Especially on multiprocessor systems, cache is shared by multiple processors, flush the cache will not only affect the course of the current processor, other processors will also affect the process of shared cache.
Know the process context switch potential performance issues, we look at, what time will switch process context.
显然，进程切换时才需要切换上下文，换句话说，只有在进程调度的时候，才需要切换上下文。Linux为每个CPU都维护了一个就绪队列，将获取进程(即正在运行和等待CPU的进程)按照优先级和等待CPU的时间排序，然后选择最需要CPU的进程，也就是优先级最高和等待CPU时间最长的进程来运行。
那么，进程在什么时候才会被调度到CPU上运行呢？
最容易想到的一个时机，就是进程执行完，终止了，它之前使用的CPU会释放出来，这个时候再从就绪队列里，拿一个新的进程过来运行。其实还有很多其他场景，也会触发进程调度，这里逐个梳理下。
其一，为了保证所有进程可以得到公平调度，CPU时间片被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其他正在等待CPU的进程运行。
其二，进程在系统资源不足(比如内存不足)时，需要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。
其三：当进程通过随眠函数sleep这样的方法将自己主动挂起时，自然也会重新调度。
其四：当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级的进程来运行。
最后一个，当发生硬件中断时，CPU上的进程会被中断挂起，转而执行内核中中断服务程序。
了解这几个场景是非常有必要的，因为一旦出现上下文切换的性能问题，他们就是幕后凶手。
线程上下文切换
说完了进程的上下文切换，我们再来看看线程相关的问题。
线程与进程最大的区别在与，线程是调度的基本单位，而进程则是资源拥有的基本单位。说白了，所谓内核中的任务调用，实际上的调度对象是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。所以，对于现场和进程，我们可以这么理解：
- 当进程只有一个线程时，可以认为进程就等于线程。
- 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的。
- 另外，线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的。
这么一来，线程的上下文切换其实就可以分为两种情况：
第一种，前后俩个线程属于不同进程，此时，由于资源不共享，所以切换过程就跟进程上下文切换是一样的。
第二种，前后两个线程属于同一个进程，此时，应为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据，寄存器等不共享的数据。
到这里你应该也发现了，虽然同为上下文切换，但同进程内的线程切换，要比多进程间切换消耗更少的资源，而这，也正是多线程代替多进程的一个优势。
中断上下文切换
除了前面两种上下文切换，还有一个场景也会也换CPU上下文，那就是中断。
为了快速响应硬件的时间，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备时间。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。
跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。所以，即便中断打断了一个正处于用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。中断上下文，其实只包括内核态中断服务程序所必须的状态，包括CPU寄存器、内核堆栈、硬件中断等参数等。
对同一个CPU来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生。同样的道理，由于中断会大段正常进程的调度和执行，所以大部分中断处理程序都短小精悍，以便尽可能快的执行结束。
另外，跟进程上下文切换一样，中断上下文切换也需要消耗CPU，切换次数过多也会耗费大量的CPU，甚至严重降低系统的整体性能。所以，当你发现中断次数过多时，就需要注意去排查它是否会给你的系统带来严重的性能问题。
小结
不管是哪种场景导致的上下文切换，你都应该知道：
- CPU上下文切换，是保证Linux系统正常工作的核心功能之一，一般情况下不需要我们特别关注。
- 但过多的上下文切换，会把CPU时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。
