Linux context, interrupts and context switching description "Go"

Transferred from: http://blog.csdn.net/tianlesoftware/article/details/6461207

I. Process context definition

When a process executes, the values in all registers of the CPU, the state of the process, and the contents of the stack, such as individual variables and data, include all register variables, process-opened files, memory information, and so on. This information is referred to as the context of the process.

The context of a process can be divided into three parts: User-level contexts, register contexts, and system-level contexts:

(1) User-level context: body, data, user stack, and shared storage area;
(2) Register context: Universal Register, Program Register (IP), processor status register (eflags), stack pointer (ESP);
(3) System level context: Process Control block task_struct, memory management information (mm_struct, Vm_area_struct, PGD, Pte), kernel stack.

When the kernel needs to switch to another process, it needs to save all the state of the current process, that is, to save the context of the current process so that it can be executed when the process is executed again. In Linux, the current process context is stored in the task data structure of the process. In the event of an outage, the kernel executes the interrupt service routine under the kernel state in the context of the interrupted process. At the same time, all resources that need to be used are preserved so that the execution of the interrupted process can be resumed at the end of the relay service.

In the Linux vmstat command, under System, there are interrupts and context switching options.

[Email protected] ~]# Vmstat 2

procs-----------Memory-------------Swap-------io------System-------CPU------

R b swpd free buff cache si so bi bo in CS us sy ID WA St

0 0 23524 13660 62952 651628 0 0 6 14 45 34 0 1 99 0 0

1 0 23524 13660 62952 651656 0 0 0 0 93 62 0 0 100 0 0

Where in represents interrupts, CS represents contxt switching.

In:the number of interrupts per second, including the clock.

Cs:the number of the context switches per second.

Unix vmstat Command

Http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5464408.aspx

Two. Interrupts and Context switching

To drastically simplify how computers work, you could say that computers does nothing more that shuffle bits (i.e. 1s and 0s ) around. All computer data was based on these binary digits, which be represented in computers as voltages (5 V for a 1 and 0 V for A 0), and these voltages is physically manipulated through transistors, circuits, etc ... When you get to the guts of a computer and start looking at what they work, it seems amazing how many operations it takes To does something simple, like addition or multiplication. Of course, computers has gotten a lot smaller and thus a lot faster, to the point where they can perform millions of thes E operations per second, so it still feels fast. The processor is performing these operations in a serial fashion-basically a single-file line of operations.

1.1 What is Context switching

       this Single-file Line could is quite inefficent and there are times Want a computer to is processing many different things at once, rather than one thing at a time. For example, more computers rely on peripherals for input, but those peripherals is often much slower than the processor itself. For instance, when a program needs some data, it may has to read that data from the hard drive first. This is a few milliseconds, but the CPU would is idle during that time-quite inefficient. To improve efficiency, computers use multitasking. A CPU can still only being running one process at a time, but multitasking gets around so by scheduling which tasks would be Running at any given Time. the act of switching from one task to another are called context switching.

--CPU can only run one process at a time, under multitasking, when the CPU processing needs to read some data from the hard disk, although this time is also calculated by miliseconds, but this time is still longer than the CPU operation, so the CPU In this waiting time, you can switch the currently processed task out and let the CPU handle the other tasks. This process is called a context switch.

Ironically, the act of the context switching adds a fair amount of overhead to the computing process. To ensure this original running program does not lose all it progress, the computer must first save the current state Of the CPU in memory before switching to the new program. Later, when switching back to the original, the computer must load the state of the CPU from memory. Fortunately, this overhead was often offset by the efficiency gained with frequent context switches.

-to ensure that the previous program did not lose its process, the computer must first save the current CPU state in memory before a task switch can be performed.

When you want to switch to the previous task, load the CPU state that was previously saved in memory to the CPU.

1.2 Context Switch:steps

In a-switch, the state of the first process must is saved somehow, so, when the scheduler gets back to the execution Of the first process, it can restore this state and continue.

The state of the process includes all the registers and the process may is using, especially the program counter, plus an Y other operating system specific data, may necessary. This data was usually stored in a data structure called a Process Control block (PCB), or Switchframe.

--The information in the process is stored in a data structure called a PCB.

In order to switch processes, the PCB for the first process must is created and saved. The PCBs is sometimes stored upon a per-process stack in kernel memory (as opposed to the User-mode stack), or there may be some specific operating system defined data structure for this information.

--When you do a switch processes, you must first create the PCB that is currently running the process and save the PCB to the kernel memory.

Since the operating system have effectively suspended the execution of the first process, it can now load the PCB and conte XT of the second process. In doing so, the program counter from the PCB are loaded, and thus execution can continue in the new process. New processes is chosen from a queue or queues. Process and thread priority can influence which process continues execution, with processes of the highest priority Checke D first for the threads to execute.

--will choose which process to load from the queue based on the priority of the process.

1.3 What is Interrupt?

If you can does context switches frequently enough, the computer appears to being doing many things at once (even though the CP U is only processing a single task at any given time). Signaling the CPU to does a context switch is often accomplished with the use of a command called an Interrupt. For the most part, the computers we ' re all using is Interrupt driven, meaning that running processes is often interrupte D by higher-priority requests, forcing context switches.

--Although the CPU can handle only one process at a time, as long as the context switch is frequent enough, we can still feel the CPU processing multiple tasks at the same time. The process by which the CPU is directed to the context switch is called interrupt.

Interrupt can be a process application with high priority, or a mandatory context switches.

From:http://kaedrin.com/weblog/archive/001657.html

Three. Interrupt Context and Process context

The processor is always in one of the following three states:

1. Kernel state, running in process context, the kernel represents the process running in kernel space;
2. Kernel state, running in interrupt Context, the kernel represents the hardware running in the kernel space;
3. User mode, running in user space.

User-space applications, through system calls, into the kernel space. At this time, the process of user space to pass a lot of variables, parameters of the value to the kernel, the kernel state when running the user process to save some register values, variables and so on.

Process context: This can be seen as the parameters that the user process passes to the kernel and the set of variables and register values that the kernel will save, and the environment at that time.

The hardware passes the trigger signal, causing the kernel to call the interrupt handler and enter the kernel space.      In this process, some variables and parameters of the hardware are also passed to the kernel, and the kernel is interrupted by these parameters. Interrupt context: Can be seen as the hardware passed over these parameters and the kernel needs to save some other environment (mainly is currently interrupted execution of the process environment).

3.1 Interrupt Context

When executing a interrupt handler or bottom half, the kernel is in interrupt context. Recall That process context is the mode of operation the kernel are in while it's executing on behalf of a process--for example, executing a system call or running a kernel thread. In process context, the current macro points to the associated task. Furthermore, because a process is coupled to the kernel in process context (because the process is connected to the kernel in the same way as the process above), process context can Slee P or otherwise invoke the scheduler.

Interrupt context, on the other hand, was not associated with a process. The current macro isn't relevant (although it points to the interrupted process). Without a backing process (because there is no process background), interrupt context cannot sleep-how would it ever reschedule? (or how to reschedule it again?) Therefore, cannot call certain functions from interrupt context. If A function sleeps, you cannot use it from your interrupt handler--this limits the functions so one can call from an Interrupt handler. (This is the limit on what functions can be used in an interrupt handler)

Interrupt context is time critical because the Interrupt handler interrupts other code. Code should is quick and simple. Busy looping is discouraged. This was a very important point; Always keep in mind that your interrupt handler have interrupted other code (possibly even another interrupt handler on a di Fferent line!). Because of this asynchronous nature, it is imperative (must) that all interrupt handlers are as quick and as simple as Possibl E. As much as possible, work should is pushed out from the interrupt handler and performed in a bottom half, which runs at A more convenient time.

The setup of an interrupt handler ' s stacks is a configuration option. Historically, interrupt handlers did not receive their own stacks. Instead, they would share the stack of the process that they interrupted[1]. The kernel stack is a and a size; Typically, that's 8KB on 32-bit architectures and 16KB on 64-bit architectures. Because in this setup interrupt handlers share the stack, they must be exceptionally frugal (must be very economical) with what data they al Locate there. Of course, the kernel stack is limited to begin with, so all kernel code should be cautious.

[1] A process is always running. When nothing else is schedulable, the idle task runs.

Early in the 2.6 kernel process, an option is added to reduce the stack size from both pages down to one, providing only a 4KB stack on 32-bit systems. This reduced memory pressure because every process on the system previously needed, and the nonswappable kernel memory . To cope with (response) the reduced stack size, interrupt handlers were given their own stack, one stack per processor, one page in size. This stack was referred to as the interrupt stack (the stack will be the interrupt stack). Although the total size of the interrupt stack was half that of the original shared stack, the average stack space availabl E is greater because interrupt handlers get the full page of memory to themselves.

Your Interrupt handler should not care what stack setup was in use or what the size of the kernel stack is. Always use an absolute minimum amount of stack space.

3.2 Process Context

One of the most important parts of a process are the executing program code. This code was read in from a executable file and executed within the program's address space. Normal program execution occurs in User-space. When a program executes a system call or triggers an exception, it enters Kernel-space. At this point, the kernel are said to being "executing on behalf of the process" and are in process context. When in process context, the current macro is valid[7]. Upon exiting the kernel, the process resumes execution in User-space, unless a higher-priority process have become runnable In the interim (transition period), in which case the scheduler is invoked to select the higher priority process.

[7] Other than process context there was interrupt context, in interrupt context, the system was not running on behalf of a process, but was executing an interrupt handler. There is no process tied to interrupt handlers and consequently no process context.

System calls and exception handlers is well-defined interfaces into the kernel. A process can begin executing in kernel-space only through one of these interfaces – all access to the kernel is through These interfaces.

3.3 Process Context and Interrupt context differences

1. The main difference between process context and interrupt context is this process context can block, while interrupt Co ntext can ' t.

2.Interrupt context mean that there is not being scheduling taking place until and unless this task ends while in the Proce SS Context every task gets the CPU time

Organize from the network

-------------------------------------------------------------------------------------------------------

Blog:http://blog.csdn.net/tianlesoftware

Email: [Email protected]

DBA1 Group: 62697716 (full); DBA2 Group: 62697977 (full) DBA3 Group: 62697850 (Full)

DBA Super Group: 63306533 (full); DBA4 Group: 83829929 DBA5 Group: 142216823

DBA6 Group: 158654907 chat groups: 40132017 chats 2 groups: 69087192

--Add group needs to explain the relationship between Oracle Tablespace and data file in notes, otherwise deny application

Linux context, interrupts and context switching description "Go"