How fast can a processor handle interrupts?

Question

I studied interruptions. Thus, most architectures are controlled by interrupts, if everything is interrupted, how fast the processor can handle it all. For example, when you press a key on the keyboard, it creates an interrupt that asks the kernel to search for a buffer for new characters, in this case, how fast the processor can serve, and also when the interrupt occurs, the processor must switch to the kernel, and this is expensive context switching. Therefore, I assume that even after all this, if the processor has good performance, I can only assume that the time between two keystrokes is a lot of time in terms of computer speed? On average, how many context switches happen in one minute? Probably, it would give me some idea of ​​what I really study, and to feel the real life .... Thanks ....

Answer 1

How quickly a few things depend:

• processor hardware and interrupt controller hardware delays (if any)
• processor clock speed (often events (or responses to them) occur no faster than this)
• the speed with which the processor can access the necessary memory (system tables (for example, a table of interrupt vectors, but there may be segment tables and page tables, etc.), a stack (an interrupted instruction code, the pointer is usually stored on the stack, so ISR can back to it), the ISR code itself and all the data that it uses). Obviously, TLB code, data and caches will be entered here.
• the time it takes for the ISR to do its job, especially if the ISRs cannot push each other out and therefore parallel interrupts must be serialized.
• interrupt priorities. Often different interrupt sources are assigned different priorities. For example, you need non-maskable interrupts, machine check interrupts (mostly interrupts that report serious hardware problems) and timer interrupts to have higher priority than, say, keyboard interrupts. When handling priority-based interrupts, all interrupts whose priority is lower than the interrupt is currently being serviced must wait. Thus, if you have many high priority interrupts, lower priority interrupts can be serviced with noticeable and variable delay times. An extreme case would be when interrupts with high priority continued indefinitely. This may be due to improper design or equipment malfunction.
• Communication and interaction with other CPUs. On MP systems, interrupt handlers can sometimes accept special blocks to gain exclusive access to a resource shared by several processors. If there is competition, the ISR will wait and all other interrupts (or all interrupts with a lower priority) will not be serviced until the current ISR completes its work.

This is a general answer to a general question.

EDIT . I forgot to mention one more thing. There are some odd processors in which some commands are repeatable (I think x86 rep movsb ), and interrupts cannot start to be serviced until the repeated instruction completes completely, which may take time equivalent to executing 1000 or even simpler individual instructions. Thus, although interrupts are enabled, some processor features may occur that prevent the ISR from starting. One such processor is the TI TMS320C54xx. With it, you should carefully monitor the FIR filter code. If the filter is long and implemented as a repeating MAC command, it will introduce a delay in serving interrupts.

Answer 2

In a normal Linux system, there is a good value, and lower values ​​have typical quanta of 800 μs, and higher values ​​have 5 ms quanta.

Linux uses heuristics to determine if a process is interactive or not. You better read this note:

https://www.cs.columbia.edu/~smb/classes/s06-4118/l13.pdf

There are several data structures related to the scheduler, such as linux keep track according to the number of interactive processes waiting on the IO binding, etc. etc.

On Windows, more than proactive multitasking, applications support the kernel through a GetMessage () API call [in the case of Windows GUI programs] .Where you call GetMessage (), this process will schedule backward when there is a message waiting to be processed in the system queue.