Does the kernel only execute on occurrence of an exception

Question

I'm learning about embedded Linux. I can't seem to find proper answers for my questions below.

My understanding is, when user-space applications are executing, if we want to perform IO for example, a system call is made which will cause a SW interrupt, generally causing the MCU to switch from non-privileged mode to privileged mode and the kernel will perform the IO on behalf of the application.

Similarity when a hardware interrupt occurs, I'm guessing this will cause the modes to switch again and execute an interrupt handler within the kernel.

What's not clear to me is, are these the only times when the kernel code gets control of the CPU?

With only one core for example, if user application code is running, shouldn't the kernel be getting control of the CPU from time to time to check things, regardless of whether an interrupt has occurred or not. Perhaps there is a periodic timer interrupt allowing this?

Also, if we have multiple cores, could the kernel just be running all the time on one core while user applications on another?

Answer 1

Read Operating Systems: Three Easy Pieces since an entire book is needed to answer your questions. Later, study the source code of the kernel, with the help of https://kernelnewbies.org/

Interrupts happen really often (perhaps hundreds, or even thousands, per second). Try cat /proc/interrupts (see proc(5)) a few times in a terminal.

the kernel will perform the IO on behalf of the application.

Not always immediately. If you read a file, its content could be in the page cache (and then no physical IO is needed). If disk access (or networking) is required, the kernel will schedule (read about preemptive scheduling) some IO to happen and context switch to other runnable tasks. Much later, several interrupts have been handled (some of which may be triggered by physical devices related to your IO), and finally (many milliseconds later) your process could return -in user space- from the read(2) system call and be running again. During that delay, other processes have been running.

Also, if we have multiple cores, could the kernel just be running all the time on one core while user applications on another?

It depends a lot (even on the kernel version). Probably the kernel is not running on the same core. YMMV.