3

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?

phrogg
  • 888
  • 1
  • 13
  • 28
Engineer999
  • 3,683
  • 6
  • 33
  • 71
  • 1
    SoC manufacturers typically refer to chips that are Linux-capable as MPUs, not MCU. *"are these the only times when the kernel code gets control of the CPU?"* -- At boot control is simply handed over to the kernel from the boot program. Yes, there is a periodic timer that interrupts. For multiple cores, no; the need for mutual exclusion in the kernel proves that your guess is wrong. – sawdust Aug 22 '18 at 19:42

2 Answers2

2

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.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
0

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

Yes, kernel can not interrupt user code from running. But Kernel will setup up a timer hardware, which will generate timer interrupt between consistent time period. Kernel utilize it to implement task schedule.

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

You can consider multiple cores system as multiple machines but they share memory, and are able to send interrupt to each other.

Zang MingJie
  • 5,164
  • 1
  • 14
  • 27
  • The kernel is handing interrupts. Then can happen every time (timers, IO devices, page faults...). Look into `/proc/interrupts` and see how often interrupts happen. And the kernel's scheduler could do context switchs. So I believe that your claim "kernel can not interrupt user code from running" is false and confusing. – Basile Starynkevitch Aug 23 '18 at 04:51
  • 1
    @BasileStarynkevitch - it could be better stated, but it is accurate - the *kernel* does not interrupt userspace, hardware does. The kernel code can't just cause the execution to switch to the kernel, without the use of a mechanism like a hardware interrupt, or without the user mode code triggering an exception. Of course the kernel sets these things up, on its own behalf or on behalf of userspace. But in the instant it happens, it's not the kernel doing the switch, it's the hardware interrupt or the userspace code. – Chris Stratton Aug 23 '18 at 21:34