Performance Analysis _linux Server Cpu_ interrupt

Interrupt

1. Indicator Range 1.1 Interrupt rate

Should be combined with CPU utilization analysis, if CPU utilization is reasonable, a large number of interrupts are acceptable. A large interrupt value, accompanied by a slow performance of the system, indicates a hardware problem

1.2 Context Switch Rate

Should be combined with CPU utilization analysis, if CPU utilization is reasonable, a large number of interrupts are acceptable.

When the context switch caused by each call is greater than or equal to 4 o'clock, the analysis needs to be combined

Online also said, need less than 5000*CPU number

2. Concept note

CPU is a kind of hardware resources, as well as any other hardware devices need to drive and management programs to use, we can take the kernel process scheduling as a CPU management program, to manage and allocate CPU resources, reasonable scheduling process to preempt the CPU, and decide which process to use the CPU, which process to wait. process scheduling in the kernel of the operating system is mainly used to dispatch two types of resources: process (or thread) and interrupt , process scheduling to different resources assigned different priorities, the highest priority is the hardware interrupt, followed by the kernel (System) process, and finally the user process. Each CPU maintains a running queue to hold those threads that can be run. The thread is either in a sleep state (blocked is waiting for IO) or is in a running state, and if the current load on the CPU is too high and the new request continues, there will be a situation where the process scheduler is temporarily not able to cope, and at this point the thread has to be temporarily placed in the operational queue.

2.1 Interrupt Rate

Number of device interrupts per second. The number of interrupt requests sent by the CPU to receive hardware drivers. When a drive has a time that needs to be kernel operation. For example, if a disk controller obtains a block of data from a disk, kernel needs to read the block, and the disk controller triggers an interrupt; kernel receives each interrupt.

In the system, the interrupt processor has a very high priority and executes very quickly. Many times, some interrupt processing does not require a high processing priority, so there are also soft-interrupt handler. If there is a lot of interruptions, kernel takes a lot of time to deal with interrupts. You can check/proc/interrupts to know which CPU the interrupt occurred on.

Interrupt rate includes the kernel due to the process of the time slice interrupt, the kernel clock frequency can be known by the following command, the total number of clock interrupts per second is = number of CPUs * Number of cores * config_hz

cat/boot/config-' Uname-r ' | grep ' ^config_hz= '

config_hz=100

The type and number of interrupts can be viewed through cat/proc/interrupts, which is the Vmstat view in (Interrupt).

2.2 Context Switch Rate

Most current CPUs can only run one process at a time, although some CPUs, such as hyper-Threading technology, can run more than one process simultaneously. Linux sees this CPU as multiple single-threaded cpu,linux cores that are constantly switching between processes, creating an illusion that one single CPU handles multiple tasks at the same time, and that switching between different process is called a Context switch.

When the system does a context switch, the CPU holds the context information for all the old process and obtains all the context information of the new process, including a large number of Linux tracking each process information, In particular, there are resources: those that process is executing, what memory is allocated, it opens those files, and so on. Switching context triggers a large amount of information movement, which is a relatively high overhead.

First, the kernel dispatch triggers the context switches. To ensure equal shared CPU time for each process, kernel periodically interrupts the running process, and if appropriate kernel scheduler starts an additional process rather than letting the current process continue, A context switch can be triggered by each periodic interrupt or a timed interrupt. The number of timed interrupts per second varies depending on the architecture and the different kernel versions.

An easy way to get the number of interrupts per second is by monitoring the/proc/interrupts file through the command cat/proc/interrupts | grep timer; Sleep 10; cat/proc/interrupts | grep timer can see how many times the timer has changed over a specified time period. If your context switch is much larger than the timer interrupt. Then context switch is more likely to be an I/O request or other long-time system call (such as sleep) generation.

When an application requests an operation that cannot be implemented immediately, kernel begins the context switch operation: Deposits the requested process and tries to switch to the other runnable process. This will allow the CPU to remain in a working state. Context switch is largely composed of two parts: interrupts and processes (including thread) switching, one interrupt (Interrupt) causes a switchover, and the creation, activation, and so on, of the process (thread) can also cause a switchover. The value of Context Switch is also associated with TPS (Transaction per Second), assuming that each call causes N cs, then you can derive

Context Switch rate = Interrupt rate + tps* N

The CSR minus the IR, is the process/thread switching, if the main process receives the request to the thread processing, the thread processing finished to return to the main process, here is 2 times the switchover. You can also use the values of CSR, IR, and TPS in the formula to derive the number of transitions that result from each thing. Therefore, to reduce the CSR, you have to work on each TPS caused by the switch, only n this value down, the CSR can be reduced, ideally n=0, but in any case, if n >= 4, then the analysis. Using Vmstat to view CS (Context Switch) is this parameter

3. Brief analysis of CPU interrupt process

You can read http://www.cnblogs.com/funeral/archive/2013/03/06/2945485.html directly here

3.1 Definition of CPU interrupt technology

ü The computer is in the execution period

An unusual or unexpected urgent handling event occurs within the system

Ücpu temporarily interrupts the currently executing program and goes to execute the appropriate event handler

ü Return to the original interrupted place after processing completed

To give a real-world example:

You are reading a book, suddenly your friend calls, so you put down the book to answer the phone, the phone after the call and then read. Phone ring--put down the book----Telephone and Continue reading this process is similar to the CPU interrupt processing process.

3.2 The role of CPU interrupts

Older CPUs handle peripheral events (such as receiving keyboard input), often using a "poll" approach. That is, the CPU is like a zhagang of the peripheral sequential access, such as it first look at the keyboard has not been pressed, some words on the processing, no words continue to see the mouse to move, and then look at the printer ... This approach makes the CPU inefficient, and the CPU and peripherals do not work at the same time (because waiting for the CPU to "patrol"). Interrupt mode means that the CPU does not actively access these devices, just to handle their own tasks. If a device wants to contact the CPU, or if it wants the CPU to handle something, it sends an interrupt request signal to the CPU. At this point the CPU will put down the work in progress to deal with this peripheral request. After the interrupt is processed, the CPU returns to continue the work before the interrupt is performed.

The role and benefits of interrupt mode

ü Allows the CPU and peripherals to work simultaneously, so that the system can respond to external events in a timely manner, and the peripheral processing speed is generally slower than cpu,cpu cannot wait for external events

ü Allows multiple peripherals to work at the same time, greatly improving the CPU utilization, but also improve the speed of data input and output.

U can make the CPU timely processing of various hardware and software failures (such as the computer in the process of running, there are unpredictable situations or some failures, such as power down, storage error, operation overflow and so on. The computer can use the interrupt system to process itself without having to shut down or report workers. ）

3.3 Types of CPU interrupts

In a computer system, depending on the source of the interrupt, it is usually divided into hardware interrupts and software interrupts

ü Hardware Interrupt

Hardware interrupts, also known as external interrupts, can be divided into: shielded interrupts, unshielded interrupts.

The interrupt can be shielded. Often generated by the computer peripherals or some interface functions, such as keyboards, printers, serial ports, etc. this type of interrupt can be blocked or ignored by the software when the CPU is handling other emergency operations. For example, if the printer is interrupted, the CPU can respond faster or slower to the printer interrupt request, because it is perfectly reasonable to have the printer wait a little longer.

Non-shielded interrupts. Caused by an unexpected event, such as power outages, memory parity errors, etc., for this type of interrupt event, cannot be masked by software, the CPU must respond unconditionally. For example, if a power outage occurs, the interrupt request must be immediately and unconditionally responded to, or any other work will be meaningless.

In the x86 architecture processor, the interrupt controller of the CPU is received by the two pins (INTR and NMI) for external interrupt request signals. of which: 1. Intr receive a masked interrupt request; 2. NMI receives unshielded interrupt request

ü Software Interrupt

Software interrupts, also known as internal interrupts and exceptions, refer to interrupts caused by calls to the intr interrupt instruction in the program. For example, WINAPI, keybd_event and mouse_event two functions, is used to simulate the keyboard and mouse input (just guess).

3.4 The process of CPU interrupts

ü Interrupt Request

The interrupt request signals the interrupt request to the CPU by the interrupt source. An external device sends an interrupt request signal to have the following conditions: the work of the external equipment has been terminated. For example, an input device can send an interrupt request to the CPU only after it is started and the data to be entered is sent to the data register of the interface circuit (that is, the data is ready for input), and the system allows the peripheral to make an interrupt request. If the system does not allow the peripheral to make an interrupt request, the peripheral request can be masked. When the peripheral interrupt request is blocked, the peripheral preparation is completed and the interrupt request cannot be made.

ü Interrupt response, processing, and return

When the interrupt condition is met, the CPU responds to the interrupt and goes to interrupt program processing. Turn off the interrupt signal receiver, save the scene (context), give the interrupt entry, transfer to the corresponding interrupt service program, process complete, return and resume the scene (context), turn on the interrupt signal receiver

ü Interrupt queuing and Interrupt award optimization

The interrupt request is random, sometimes multiple interrupt sources are present and an interrupt request is made. The CPU can only respond to requests for one interrupt source at a time. The CPU is unlikely to treat all interrupt requests equally, and it prioritizes a priority order based on the nature of each interrupt source's work. When multiple interrupt sources request interrupts at the same time, they are queued in this order of priority, waiting for CPU processing.

3.5 Multi-core CPU processing of interrupts

Interrupt handling for multicore CPUs is very different from single cores. The multi-core processor core needs to communicate through the interrupt mode, so the CPU chip has both the local interrupt controller of each processor core and the global interrupt controller which is responsible for the interrupt distribution between the various cores. Today's multicore processors primarily use the APIC (Advanced Programmable Interrupt Controllers) for interrupt handling and interrupt control, a high-level programming interrupt controller. It is a distributed architecture based on the two basic functional units of the interrupt controller-the local unit and the I/O unit. In multicore systems, multiple local and I/O APIC cells can operate as a whole via the APIC bus.

The APIC functionality has the ability to accept interrupts from the internal or external I/O APIC from the processor interrupt pin and then send these interrupts to the processor core for processing. Receive and send in-core interrupt messages in multicore processor systems

For interrupt requests made by external devices, the global interrupt controller receives the request and decides which core processing to give to the CPU. It can also be programmed for APIC so that all interrupts are handled by a fixed CPU.

4. Interrupt Handling in Linux

This section of the article can be read directly http://www.uml.org.cn/embeded/201304021.asp

4.1 Interrupt Implementation

In Linux drivers, implementing an interrupt for a device consists of two steps: Registering the interrupt with the kernel, and implementing the interrupt handler function.

In the field site mode, the CPU takes a 1KB space in memory starting from 0 as a table of interrupt vectors. Each item in the table accounts for 4 bytes. However, in protected mode, the interrupt vector table with the 4-byte table entry does not meet the actual demand, so the information and offsets based on the reflection mode are sufficient to make the table entries of the interrupt vector table consist of 8 bytes, and the interrupt vector table is called the Interrupt Descriptor List (IDT). A start address that describes the interrupt Descriptor Descriptor Register (IDTR) is added to the CPU to hold the interrupt descriptor.

An external device generates a corresponding interrupt when it needs to do something related to the operating system. The device sends a high level to the interrupt controller through the corresponding interrupt line to generate the interrupt signal, while the operating system takes the interrupt from the interrupt controller's status bit to the interrupt line. And only if the device has control over an interrupt line, it can send a signal to the interrupt line. Also due to the more and more peripherals now, in the middle of the disconnection is very valuable resources can not be one by one correspondence. Therefore, before the disconnection in use, the corresponding interrupt line must be applied. Regardless of whether you are using a shared interrupt or an exclusive interrupt, the application process is to scan all of the interrupt lines first to see which ones are not occupied and select one as the IRQ for that device. Second, apply the appropriate IRQ by interrupting the application function. Finally, depending on the application results, see if the interrupt can be executed

4.2 Interrupt handling mechanism

The next half of Linux interrupts are handled in three ways: soft interrupt, Tasklet, and task queue.

4.2.1 The simplest interrupt mechanism

The simplest interrupt mechanism is to fill in the interrupt vector table with the instructions to jump to the corresponding handler function, and then implement the required functions in the processing function, which is obvious, simple and straightforward, as the chip manual says. Similar:

4.2.2 The lower half of the

The first thing that the interrupt handler does is block interrupts (or do nothing, because often if the if bit is not cleared, the shield is interrupted) and of course only the same interrupt is masked. The reason to block interrupts is because new interrupts call the interrupt handler again, causing the damage to the original interrupt processing site. That destroys the interrupt context.

With the continuous complexity of the system, the interrupt processing function to do more and more things, too late to receive new interrupts. The interruption is lost, which obviously does not work, resulting in a new mechanism: separating the interrupt reception and the interrupt processing process.

The Linux interrupt is divided into two halves: the top half (tophalf) and the lower half (bottom half). The function of the upper part is "register Interrupt", when an interrupt occurs, it performs the corresponding hardware read and write, and then hangs the lower half of the interrupt routine into the lower half of the device execution queue. As a result, the top half executes quickly and can serve more interrupt requests. However, only a "registration interruption" is not enough, because an interrupted event can be complex. As a result, Linux introduces a lower half to complete the most mission of interrupting events. The biggest difference between the lower half and the top half is that the lower half is interruptible, the upper half is non-interruptible, the lower half is almost all done by the interrupt handler, and can be interrupted by a new interrupt! The lower half is relatively less urgent and usually time-consuming, so the system runs its own schedule and does not execute in the context of the interrupt service.

From this, only look at the treatment of int0. FUNC0 is the interrupt receive function. Interrupts can simply trigger func0, while FUNC0 can do more, and it can use caching mechanisms such as queues between Funca. When another interrupt occurs, the FUNC0 is triggered, then an interrupt request is sent to the cache queue, and then the Funca is processed. Since the func0 do is very simple, it does not affect the int0 reception. And when the func0 returns, it will enable int0, so the Funca execution time is longer and will not affect the int0 reception.

4.2.3 Soft Interrupt

Linux interrupt processing. As an operating system, it is clearly not possible to allow each outage to be fragmented, and unified management is a must. The common part of the non-interruptible part is placed in the function DO_IRQ, which is implemented by REQUEST_IRQ when the interrupt handler needs to be added. The lower half is placed in the DO_SOFTIRQ, which is the soft interrupt, and the corresponding processing function is added through OPEN_SOFTIRQ.

4.2.4 Tasklet

As the number of interrupts increases, the soft interrupts are not enough, and the second half has evolved. Soft interrupts are handled in the form of polling. If it happens to be the last interrupt, you must loop through all of the interrupt types before you can finally execute the corresponding handler function. It was clear that the developers in order to ensure the efficiency of polling, so limit the number of interrupts is 32. In order to improve the processing efficiency, the Tasklet mechanism was created to increase the number of interrupt processing.

Tasklet uses a non-discriminatory queuing mechanism, which executes only when there is an interruption, eliminating the pain of a circular look-up table. As a new mechanism, Tasklet can obviously take on more advantages. Just at this time the SMP is getting more and more fire, so the SMP mechanism is added in the Tasklet to ensure that the same interrupts are executed on only one CPU. In the era of soft interruptions, this is clearly not considered. Therefore the same interrupt can be executed simultaneously on two CPUs, which is likely to cause a conflict. Tasklet The advantages of no type quantity limit, high efficiency without circular check table, support SMP mechanism;

4.2.5 Task Force columns

The previous mechanism no matter how toss, one thing will not change. They are all in the context of the interrupt. That is, they cannot be suspended. And because it is serially executed, it can cause delays in other interrupt responses as long as one has a longer processing time. In order to accomplish these impossible tasks, a work queue appears. The work queue is plainly a set of kernel threads to use as an interrupt daemon. Multiple interrupts can be placed in one thread, or each interrupt can be assigned one thread. The work queue encapsulates threads and makes them easier to use. Because the work queue is a thread, we can use all the methods that can be used in threads.

Tasklet is not necessarily executed in an interrupt context, it is also possible to execute in a thread. If the number of interrupts is large and the interrupts are self-priming (the interrupt handler causes a new interrupt), it is possible that the CPU has been executing the interrupt handler here, causing the user process to never get the scheduled time. To avoid this situation, the Linux discovery of an excessive number of interrupts, will put the extra interrupt processing in a separate thread to do, that is, KSOFTIRQD thread. This ensures that the response speed is not long, but also ensure that the interruption of the user process will not starve.

The problem is that we cannot guarantee that our tasklet or soft interrupt handlers will be executed in the thread, so there are some methods that cannot be used by the process, such as abort scheduling, long delay, and so on.

Linux implementation of the lower half of the mechanism is mainly tasklet and work queue

4.3 Interrupt function

The first thing associated with interrupt handling in Linux device drivers is the API Request_irq () and FREE_IRQ () that request and release the IRQ.

4.3.1 Interrupt Registration function

Request_irq,int REQUEST_IRQ (unsigned int irq, void (*handler) (int, void*, struct Pt_regs *) for implementing interrupt registration function, unsigned long IRQ Flags, const char *devname, void *dev_id) returns 0 for success, or returns an error code

Parameter description:

üunsigned int IRQ//hardware interrupt number to be requested

Üvoid (*handler) (int,void *,struct Pt_regs *)//is an interrupt handler that is registered with the system and is a callback function that the system calls when the interrupt occurs

üunsigned long Irqflags//properties related to interrupt management, if the sa_interrupt is set to indicate that the interrupt handler is a fast handler, the fast handler is invoked to mask all interrupts, the slow handler is not masked, and if the SA_SHIRQ is set, Multiple devices are sharing interrupts.

Üconst char * devname//device name

Üvoid *dev_id used when sharing interrupts, as a pointer to a shared interrupt line. It is generally set to the device structure itself or null. It is a unique identifier used when releasing the interrupt line and may also be driven to point to its own private data area to identify which device is interrupting; This parameter is typically a pointer to the device's data structure in a real driver. It is passed to the interrupt handler's void *dev_id when the interrupt handler is called. If the interrupt is not shared dev_id can be set to NULL.

Flags parameter description of options related to interrupt management

#define IRQF_DISABLED 0x00000020/* Interrupt Forbidden */

#define IRQF_SAMPLE_RANDOM 0x00000040/* For system-generated random number use */

#define IRQF_SHARED 0x00000080/* Can be shared between devices */

#define IRQF_PROBE_SHARED 0x00000100/* probe sharing interrupt */

#define Irqf_timer 0x00000200/* dedicated to clock interrupts */

#define IRQF_PERCPU 0x00000400/* Interrupt per CPU cycle */

#define IRQF_NOBALANCING 0x00000800/* Reset Interrupt */

#define Irqf_irqpoll 0x00001000/* sharing interrupt based on registration time */

#define Irqf_oneshot 0x00002000/* After the hardware interrupt is processed */

#define Irqf_trigger_none 0x00000000/* No trigger interrupt */

#define Irqf_trigger_rising 0x00000001/* Specifies the interrupt trigger type: The rising edge is valid */

#define Irqf_trigger_falling 0x00000002/* Interrupt trigger type: Falling Edge valid */

#define Irqf_trigger_high 0x00000004/* Specifies the interrupt trigger type: High Active */

#define IRQF_TRIGGER_LOW 0x00000008/* Specify interrupt Trigger type: active Low */

#define IRQF_TRIGGER_MASK (irqf_trigger_high| Irqf_trigger_low|\irqf_trigger_rising| irqf_trigger_falling)

#define IRQF_TRIGGER_PROBE 0x00000010/* Trigger detection Interrupt */

Description: If you set irqf_disabled (Sa_interrupt), it is a "fast" interrupt handler that is otherwise a "slow" interrupt handler. Fast interrupts guarantee the atomicity of interrupt processing (not interrupted), while slow interrupts are not guaranteed. That is, the "on interrupt" flag bit (processor if) is closed when the fast interrupt handler is run, so when the service is interrupted, it is not interrupted by other types of interrupts, and when slow interrupt processing is called, other types of interrupts can still be serviced.

Üirqf_shared (SA_SHIRQ)

This bit indicates that interrupts can be shared between devices. A shared outage is a way to hang different devices on the same interrupt signal line. Linux support for sharing is primarily for PCI devices. Shared interrupts are also registered through the REQUEST_IRQ function, but there are three special places: when requesting a shared interrupt, you must specify the irqf_shared bit in the flags parameter; The DEV_ID parameter must be unique; In a shared interrupt handler, you cannot use DISABLE_IRQ (unsigned int IRQ), if this function is used, other devices that share the interrupt signal line will also be unable to use interrupts and will not function properly.

4.3.2 Interrupt Handling function

The interrupt handler is the normal C code, which runs in the context of the interrupt, and its behavior is limited by the inability to send or receive data to the user space, the inability to use a function that might cause blocking, and the function that could cause the dispatch.

void Short_sh_interrupt (int irq, void *dev_id, struct pt_regs *regs)//Determine if the device has interrupted

{value = INB (short_base);

if (! ( Value & 0x80)) return;//clears the interrupt bit (this step is not required if the device supports automatic purge)

Outb (Value & 0x7F, short_base);//interrupt processing, usually data reception

。。。。。。。。。 /* Wake up process waiting for data */

Wake_up_interruptible (&short_queue);

4.3.3 Release Interrupt

When the device no longer needs to use interrupts (usually when the driver is unloaded), they should be returned to the system, using the function void Free_irq (unsigned int irq, void *dev_id)

5. References

Http://www.cnblogs.com/funeral/archive/2013/03/06/2945485.html

Http://www.uml.org.cn/embeded/201304021.asp

Http://blog.chinaunix.net/uid-27139412-id-3955865.html

http://blog.163.com/[email protected]/blog/static/748333872010047527968/

http://blog.csdn.net/stanjiang2010/article/details/5760743

Performance Analysis _linux Server Cpu_ interrupt