Multitasking: Should the kernel have its own running task?

[gravaera]

Remember, a "maintenance" thread is spawned once, and then assigned a "background" level priority (whatever that means to the particular kernel), so there is no need for any call to "sleep" from the thread; the very fact that it is scheduled with a "background" or "low" priority ensures that it will not be running when more important work is to be done :O The scheduler will always be picking higher priority threads in preference to the maintenance thread.

--All the best,
gravaera

[bluemoon]

We may be both right, it all depends on how your scheduler work.

On my kernel, even lowest priority task still get chance to execute even some other task are not sleeping, and for at least a unit of time-slice.
This resolve to the temporal distance of timer interrupt, or about 1ms
If the maintenance thread do not withdraw it's time slice by sleep, wait, yield, similar ways of blocking,
the time slice will be busy-wasted until next chance to be preempted.

[bluemoon]

Remember, a "maintenance" thread is spawned once, and then assigned a "background" level priority

And you also said,

For any sequence that the kernel must run which was not prompted first by userspace (for example, bootstrapping, or cache flushing in the background, or heap compacting) the kernel should spawn a thread for that action, and have it killed when it is no longer needed

Does cache flushing in the background, heap compacting not counted as maintenance? I'm confused.

[gravaera]

Remember, a "maintenance" thread is spawned once, and then assigned a "background" level priority

And you also said,

For any sequence that the kernel must run which was not prompted first by userspace (for example, bootstrapping, or cache flushing in the background, or heap compacting) the kernel should spawn a thread for that action, and have it killed when it is no longer needed

Does cache flushing in the background, heap compacting not counted as maintenance? I'm confused.

The sequence may be needed constantly, and never need to be killed Many kernel actions not prompted from userspace may be short burst actions, such as bootstrap, or say, putting the computer to "sleep" after a long time of inactivity from userspace. Other "actions" from the kernel may be long-time things it "does" that may need low priority scheduling :O Remember, my original angle was to discuss the idea of not having a "kernel main thread" so to speak (ref: thread title), and to have a fully responsive kernel design model. Basically, I was proposing that things such as "bootstrapping" aren't part of an idealistic "kernel main", so to speak, but rather just non-response based actions which should be treated as special case threads that perform the action, then go away when they're not needed.

Err, to compound that a bit better: consider having a single "kernel process" which actually actively "runs". This kernel process may then be responsible for triggering the various management/maintenance actions the kernel may need done and may run at low priority, and loop, running each maintenance action in sequence, and each would have to wait until its turn came back around. So if the heap needs compacting now, it may have to wait until say, the "kernel thread" gets out of its call into the VFS cache flushing code. Instead, one could have all kernel "actions" be separate threads, such that the kernel isn't designed to be "doing" things actively. The difference is mainly in the approach, and design; it's doens't imply phenomenal change, but a small paradigm ideology shift that may produce more orderly kernel job scheduling

--Hope I cleared that up,
gravaera

[bluemoon]

That's what I called kernel main thread. It doesn't matter if the process spawn more threads to simultaneously do the actual job at other process/thread.

You eventually need something to trigger the regular jobs, either by a kernel process/thread, by a chance at syscall, timers, etc.

EDIT: however, I like the idea of not doing the actual job inline within kernel main, but signal the other thread or component to do.

[Caleb1994]

Whoa, sorry guys. I was out of the country for a month.

I was not able to work on any coding while I was gone, so I'm pretty much in the same place

I understand the fact that processes will be removed from the ready queue (by "sleeping") but where do they go? If the process is not being executed, who puts it back in the ready queue? I would assume the scheduler, but how does the scheduler know when to replace it? Lets say the process is waiting for a specific event (ignoring "sleeping", and dealing with blocking), how does the scheduler know when that event has happened, since it is low-level code, and probably has no idea about the event/semaphore/message that the process is waiting on.

Like I said, I understand the idea, but I can't get my head around the implementation.

[piranha]

They can be placed in a different queue, or have a flag set in them that has the scheduler skip over them while looking for the next task to run. In my implementation, the scheduler goes to the next task in the linked-list of tasks, and checks the status flag. If it's sleeping, it checks to see if the task can be awakened. If it can, then it sets the flags to runnable, and runs that task. If it can't be awakened, it skips it. The way my scheduler knows is that the task structure contains a pointer to an unsigned int, and when that value (*p) becomes something, then the task is awakened.

-JL

[saptrap]

...how does the scheduler know when that event has happened, since it is low-level code, and probably has no idea about the event/semaphore/message that the process is waiting on.

In many cases, such as a semaphore, the semaphore unlock call would check it's wait queue to see if anyone is blocked, select the next process in line and then set it's status back to "ready". After all, it was the semaphore lock call that put it to sleep in the first place. The next time the scheduler is called, the process will be available to run.

-Mike

[rdos]

I have one "idle" thread per CPU. They are running a hlt-loop. I also have a few server threads that are spawned by kernel device-drivers, and that exclusively run in kernel-mode. In my system, there is at least one activity that demands a kernel house-keeping thread, and it is process termination clean-up. Thread termination clean-up is also handled by the same kernel-thread as this is easier than doing it in the terminated thread.