Storing and retrieving the process control unit
When a process is running, the contents of the circuit board (which is in the core of the kernel memory?) Are loaded into processor registers and status registers, kernel stack pointers, user stack pointers, etc.
When there is a context switch in another process, the current "context" is saved to the PCB and the switch is transferred to the new PCB.
Now that the kernel wants to put this PCB back into the "context", how does it find this PCB that is currently in memory? What information helps the kernel find the PCB that is in memory?
source to share
It is a scheduling task to look for processor availability, then only a context switch happens. As soon as the kernel is available, the program counter value for the stored circuit packs in the kernel is received and transferred to the CPU registers. I would like to say that PCBs are stored on a stack using the kernel.
source to share
- PCB: This is a data structure that can be part of the OS or User. But because it is sensitive to data structure almost everywhere, the PCB is part of the kernel data structure.
- The PCB is basically stored as a process kernel stack that resides in kernel space, and the kernel has access to that, which is protected from any users.
- Process switching is a scheduling feature and is a kernel module. There are many scheduling algorithms for determining a process switch (long / short / medium, etc.).
- The scheduler now determines which process will be started next, not by the kernel. The kernel function is to provide a service when called (system calls / interrupts / hooks).
- As a kernel module, it "
scheduler
" has access to all data structures in the kernel, so it defines the sequence of processes (this can be a proactive or a shared scheduler). - Each process has its own PCB, so the active / worker process gets its PCB loaded into processor registers and other necessary sections using the previously saved PCB (mostly) up to the kernel stack.
Always keep in mind: The core is like a waiter serving what is asked for, who knows nothing, doing everything like a donkey's job (albeit most importantly) as said.
source to share
I would like to provide information on the bit details (&, to make it easy to understand, consider that there is one kernel thread for each process).
There is now a thread context (eip, ebp, esp, pagedir, kstack, kstacksize) with each kernel thread (kthread). Thus, since we all know the life cycle of a thread / process, it goes through states such as - "Start, Runnable, wait, exit" . When a thread is running, its context is in the "context_t" kernel data structure stored somewhere in the kernel address space. and the kernel stack contains a pointer to this data structure When a thread switch occurs (in more technical terms, we should say context_switch) (the reason could be the scheduler timeout, I / O completion, etc.), the Thread is queued in the kernel data structure of the run queue (while waiting for it to get the CPU).
When the states become "Running", the context switch happens again and now the context_t is loaded. which has all the necessary pointers to access previously stored data items, which will now be used to continue formatting a previously stopped state.
All kernel data structures are stored in the kernel address space (> 0xc0000000), and the thread has pointers to this block of context. (as threads switch, a new thread points to its context - again a context switch, the next thread points to its own data structure.
source to share