New approach to scheduling (microkernel)

[vlad9486]

Isn't that what group scheduling in the CFS was designed to eliminate? Scheduling is somewhat more sophisticated than simply dividing CPU time by the number of threads in the system.

Yes, I agree, the same thing is doable in the kernel. But it will be difficult to tweak the scheduler. Maybe one day the scheduler will accept bytecode from userspace that overrides the scheduling algorithm, but that is too complex for me.

[rdos]

There is a definite difference here since the kernel scheduler can implement locks that prevents scheduling at critical times.

It doesn't need to be waits for interrupts. A thread can be blocked on a mutex waiting for another thread to release it. In kernel space, a thread can be blocked on a kernel mutex.

Does this problem disappear if my kernel doesn't have a kernel mutex? Also. The kernel doesn't do any scheduling, memory allocation, or memory mapping. It only switches address spaces. I don't even think that the kernel needs a stack.

I think at the minimum kernel must handle physical memory, and page fault handling which assign physical memory to linear process memory. It's possible to create a lock free physical memory allocator, so I suppose you might not need blocking objects in kernel.

[rdos]

Isn't that what group scheduling in the CFS was designed to eliminate? Scheduling is somewhat more sophisticated than simply dividing CPU time by the number of threads in the system.

Yes, I agree, the same thing is doable in the kernel. But it will be difficult to tweak the scheduler. Maybe one day the scheduler will accept bytecode from userspace that overrides the scheduling algorithm, but that is too complex for me.

Scheduling and task switching is not the same thing. I think it is possible to have the scheduling algorithm in a user process, but real time task switching must be in kernel. I have a kernel thread for scheduling, and load balancing, but it probably would be possible to move it to a server process if desired.

[iansjack]

I don't even think that the kernel needs a stack.

A kernel that makes no use of functions, procedures, or local variables will certainly be an interesting proposition.

[vlad9486]

I think at the minimum kernel must handle physical memory, and page fault handling which assign physical memory to linear process memory. It's possible to create a lock free physical memory allocator, so I suppose you might not need blocking objects in kernel.

After meltdown and spectre, I don't like the idea that all physical memory is mapped to kernel space. For security reasons, the kernel should know as little as possible. So I just reserve 1/128 of the physical memory for buddy. I understand that this is wasteful. It could be mitigated in the future. Since I have dedicated memory that contains buddy stuff, it could be placed on some user space memory and user space code will allocate/deallocate physical memory.

Same thing with mapping. The page table is mapped to itself, this gives me 2Mb, where first 4kb is a page where I could write physical address and it will appear in the rest of 2Mb. I can have one such loop page per CPU. And this can be mapped in user space. The only thing user space cannot do is invalidate TLB (it could be done by syscall).

This allows me to have a kernel that is only a few kilobytes. And doesn't have mutable memory so far.

I target risc-v, it has tagged MMU, the TLB can hold translations belonging to different address spaces simultaneously. So, no need to flush the TLB. I believe this will mitigate the performance penalty on address space switching.