CODEWITHSUNDEEP
linux-kernelsystem-callscontext-switch
cong
cong

Reputation: 1187

When will a process resume execution in user mode from kernel mode after a system call?

I used to think that a process may switch from user mode to kernel mode by system call, after the kernel routine is done, it will check if there is any other process which has higher priority before return to user mode, if not, it will return to user mode directly. But Understanding the Linux Kernel, 3rd Edition 1.6.1. The Process/Kernel Model just confused me:

On a uniprocessor system, only one process is running at a time, and it may run either in User or in Kernel Mode. If it runs in Kernel Mode, the processor is executing some kernel routine. Figure 1-2 illustrates examples of transitions between User and Kernel Mode. Process 1 in User Mode issues a system call, after which the process switches to Kernel Mode, and the system call is serviced. Process 1 then resumes execution in User Mode until a timer interrupt occurs, and the scheduler is activated in Kernel Mode. A process switch takes place, and Process 2 starts its execution in User Mode until a hardware device raises an interrupt. As a consequence of the interrupt, Process 2 switches to Kernel Mode and services the interrupt.
enter image description here

The following description just don't make sense

Process 1 then resumes execution in User Mode until a timer interrupt occurs, and the scheduler is activated in Kernel Mode.

I think that returning to user mode have noting to do with interrupt and what does it mean by "scheduler is activated in Kernel Mode"?

Upvotes: 0

Views: 1140

Answers (1)

Wyzard
Wyzard

Reputation: 34563

The scheduler is the part of the kernel that performs task switching. Each time the scheduler runs, it chooses which process should have control of the CPU next, and switches to it. The scheduler needs to run often enough to ensure that all processes get a fair share of time on the CPU.

System calls can invoke the scheduler, but that alone isn't sufficient, because a process might spend a long time running code in user space, not making any system calls. To ensure that the scheduler runs often enough, the kernel configures a hardware timer to periodically send interrupt signals to the CPU. Each time the interrupt signal occurs, the CPU stops running the user program, switches to kernel mode, and runs an "interrupt handler" in the kernel that calls the scheduler. Since it's triggered by a timer instead of by code, this works even if the user program isn't making any calls into the kernel.

Upvotes: 1

Related Questions