Preemptive kernel
Preemptive kernel
I think a preemptive kernel would be very useful for the multiprocessing to kill the deadlocks.
What do you think about this?
Have you any idea about implementing this?
What do you think about this?
Have you any idea about implementing this?
Rewriting virtual memory manager - Working on ELF support - Working on Device Drivers Handling
http://sourceforge.net/projects/jeko - Jeko Operating System
http://sourceforge.net/projects/jeko - Jeko Operating System
Re: Preemptive kernel
I'd say no. As the kernel might be working on more places which increases the chance that a deadlock occurs.
Although the chance a deadlock locks up the kernel is lower, but data might be inconsistent.
Although the chance a deadlock locks up the kernel is lower, but data might be inconsistent.
Re: Preemptive kernel
There are no real disadvantages to having a preemptible kernel, apart from coding time and effort. Whether you actually preempt in the kernel is another matter - linux for example provides a config switch so that you can choose.
Re: Preemptive kernel
JamesM wrote:preemptible kernel
http://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels
Rewriting virtual memory manager - Working on ELF support - Working on Device Drivers Handling
http://sourceforge.net/projects/jeko - Jeko Operating System
http://sourceforge.net/projects/jeko - Jeko Operating System
Re: Preemptive kernel
However, how can I implement preemption in the kernel?
Rewriting virtual memory manager - Working on ELF support - Working on Device Drivers Handling
http://sourceforge.net/projects/jeko - Jeko Operating System
http://sourceforge.net/projects/jeko - Jeko Operating System
Re: Preemptive kernel
To do preemption in the kernel just don't do anything to prevent it. So on a system call don't disable interrupts and make sure your scheduler doesn't distinguish between kernel mode and user mode when scheduling threads.
Re: Preemptive kernel
Are there anything to do related to security?thooot wrote:To do preemption in the kernel just don't do anything to prevent it. So on a system call don't disable interrupts and make sure your scheduler doesn't distinguish between kernel mode and user mode when scheduling threads.
Rewriting virtual memory manager - Working on ELF support - Working on Device Drivers Handling
http://sourceforge.net/projects/jeko - Jeko Operating System
http://sourceforge.net/projects/jeko - Jeko Operating System
Re: Preemptive kernel
What's your point? "preemptible" means the kernel is designed to be able to be preempted. "preemptive" means the preemption is enabled. It can be preemptible without being preemptive.Jeko wrote:JamesM wrote:preemptible kernelhttp://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels
Re: Preemptive kernel
Not that I'm aware of. You do need to watch out for places where you don't want to be preempted though (such as when you're holding a spinlock).Jeko wrote:Are there anything to do related to security?
Re: Preemptive kernel
Ah...SorryJamesM wrote:What's your point? "preemptible" means the kernel is designed to be able to be preempted. "preemptive" means the preemption is enabled. It can be preemptible without being preemptive.Jeko wrote:JamesM wrote:preemptible kernelhttp://en.wikipedia.org/wiki/Preemptive_multitasking wrote:Some modern systems have preemptive kernels
So a preemptive kernel is a normal kernel with multitasking enabled?thooot wrote:Not that I'm aware of. You do need to watch out for places where you don't want to be preempted though (such as when you're holding a spinlock).
Rewriting virtual memory manager - Working on ELF support - Working on Device Drivers Handling
http://sourceforge.net/projects/jeko - Jeko Operating System
http://sourceforge.net/projects/jeko - Jeko Operating System
Re: Preemptive kernel
It's not necessarily good to enable preemption in most parts of the kernel. Imagine a microkernel that has very fast system calls. All the work is done by user space application. When a user space process calls a write() system call (of course I'm talking about non-blocking system calls here) in order to write some bytes to a pipe (or message box) the kernel generally has to acquire a spinlock or semaphore before it can modify the pipe's buffer. If the kernel is interrupted before releasing the lock it might switch to another processes that also tries to access the pipe. The second process has to wait until the first process finishes its write() operation. Now imagine that many processes that access a single (kernel-) resource that is currently locked by another process. If preemption was disabled for the write() system call throughput would be greatly improved (at least for all threads on the same processor). It's not always good to enable preemption for every system call; especially for system calls that are very fast and have a constant worst-case running time. write()ing to a pipe is usually O(size_of_pipe_buffer) with very small constants. Even if write() is not preemptive interrupts will still be processed without any significant delay.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].