How the kernel may not be proactive and still have several control paths

Question

In the course of operating systems, which I took some time ago, we worked on the old, non-proactive Linux kernel (2.4.X). However, we were told that there could be several control paths in the kernel at the same time. Is this not contrary to the unconditioned nature of the kernel? EDIT: I mean, there is no context switch inside the kernel. The last time I tried to ask this question, I got the answer "well, the Linux kernel is proactive, so there are no problems."

Answer 1

In kernel 2.4, although the kernel code cannot be arbitrarily reproached with another kernel code, the kernel code may still voluntarily refuse the CPU to sleep (this is obviously a fairly common case).

In addition, kernel code can always be preceded by interrupt handlers (unless it specifically turned off interrupts), and the 2.4 kernel also supports SMP, allowing multiple processors to run simultaneously inside the kernel.

Answer 2

The Linux kernel can work in the context of an interrupt or in the context of a process (user). A process context means that it runs on behalf of the process that caused the system call. The context of an interrupt means that it works on behalf of an interrupt (hardware interrupt, softirq, ...).

When you talk about proactive multitasking, it means that the kernel can decide to stop some task in order to start another task. When you talk about proactive kernels, this means that the kernel can decide to run another kernel code itself.

Now, before Linux becomes a proactive kernel, you can run the kernel code on multiple processors, and the kernel code can be interrupted by hardware interrupts (which may cause softirqs to run before returning ...). Anticipatory kernels mean that the kernel can also be excluded from the kernel code of the process context in order to avoid long latencies (anticipatory Linux appeared from the Linux real-time tree).

Of course, all this is best explained in Rusty Russell's Unreliable Kernel Hacking Guide and the Unreliable Kernel Lock Guide .

EDIT:

Or, trying to explain it better when a task calls a script on an unmanaged kernel, this task cannot be trained until syscall ends (possibly with EINTR, but it can take a long time). A proactive kernel eliminates this problem, which will lead to lower mid-term and worst-case latencies for other tasks awaiting completion.

Answer 3

A non-overexposed kernel means that the kernel does not perform context switching on behalf of another process or interrupts another running process. It can still be multiprocessor, implementing collaborative multitasking, when actually running processes themselves provide control of the kernel or other processes. So yes, you can have multitasking and an uncaught core.

There is no context switch in the kernel for MONOLITHIC cores, but of course there is multitasking performed by the kernel .... so you still have multitasking and continuity

Answer 4

The Linux kernel unloads a lot of work on kernel threads, which can be scheduled internally and externally along with user space tasks, regardless of kernel priority. Even your old 2.4 kernel has these kernel threads, although less than the modern 2.6 kernel. The 2.6 kernel now has several priority levels that can be selected at compile time, but full succession is not the default.