how quick can the processor handle the interrupts

Question

I was studying about interrupts. So most architecture are interrupt driven, if everything is interrupt driven, how fast the processor can handle all of those. For example, while pressing a key board keys, it creates an interrupt asking the kernel to look for the buffer for new characters, in that case, how fast the processor can serve, also when an interrupt is put, the processor needs to switch to kernel space and that costs a lot in terms of context switch. So I assume, even after all these if the processor has a good performance, then I can only assume that the time between two key strokes is lots of time in terms of computer speed? One an average, how many context switch happens in one minute? I guess that would give me some idea about what I am really studying and to get an real life feel.... Thanks....

Answer 1

How quickly depends on multiple things:

1. latencies in the hardware of the CPU and the interrupt controller (if any)
2. the CPU clock rate (often, events (or responses to them) occur no faster than that)
3. the speed with which the CPU can access the needed memory (system tables (e.g. the interrupt vector table, but there may be segment tables and page tables and others), the stack (the interrupted code instruction pointer will be typically saved on the stack, so the ISR can return to it), the ISR code itself and all the data it uses). Obviously, code, data and TLB caches are going to contribute here.
4. the time needed for the ISR to do its work, especially if ISRs cannot preempt each other and so concurrent interrupts have to be serialized.
5. the interrupt priorities. Often, different interrupt sources are assigned different priorities. For example, you'd want non-maskable interrupts, machine-check interrupts (basically, interrupts reporting serious hardware issues) and timer interrupts to have higher priority than, say, keyboard interrupts. In priority-based interrupt handling, all interrupts, whose priority is lower than the interrupt being currently serviced, will have to "wait". So, if you have lots of high priority interrupts, lower priority interrupts can be serviced with noticeable and varying lag. The extreme case would be when high priority interrupts keep coming endlessly. This may be due to improper design or hardware malfunction.
6. communication and interaction with other CPUs. In MP systems, interrupt handlers may sometimes take spinlocks to get exclusive access to a resource shared among multiple CPUs. If there's contention, the ISR will wait and all other interrupts (or all interrupts of lower priority) won't be serviced until the current ISR finishes its work.

That's a general answer to a general question.

EDIT: I've forgot to mention one more thing. There exist some odd CPUs in which certain instructions are repeatable (think of x86's rep movsb) and interrupts can't start getting serviced until the repeated instruction fully finishes, which may take time equivalent to executing some 1000 or even more simple individual instructions. So, despite interrupts being enabled, there may be some CPU quirks not letting the ISRs to start running. One of such CPUs is TI's TMS320C54xx. With it you have to careful around FIR filter code. If the filter is long and is implemented as a repeated MAC instruction, it will introduce a latency in interrupt servicing.

Answer 2

In a normal linux system there is a nice value , and lower nice values have around typical 800ms quanta value and higher nice value have 5ms quanta.

Linux system uses heuristics to decide whether the 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 that regarding the scheduler, Such as linux keep track on number of interactive processes wait on IO bound , etc etc.

In windows more than preemptive multitasking , the application programs support the kernel through the GetMessage() API call[in the case of windows GUI programs].Where when you call GetMessage() , that process will schedule back when there is a message pending to be processed in it's system queue.