OSDev.org

Hi, I was at school today thinking (In algebra btw) and I was thinking of stuff for Chronos, and I came up with an idea.
Let's say this 'chore list' looks like this when the computer starts:
0-0-0-0-0-0-0-0-0-0
C-1-2-3-4-5-6-7-8-9
^
Where C is current and n is chores till C.
The line above it represents the chore assigned to that slot.
Every clock tick, the chore C is executed, and every chore besides C is shifted towards C.
Also, in slot 1, if the chore is quite simple, it gets executed right after C is executed.
(FYI , I was thinking a 0 would indicate nothing for the kernel to do, and just call the scheduler.

This thing that does a list of other things look a lot like a scheduler, that when done calls another scheduler. What is this supposed to be for?

It is for the kernel to dynamically react to tasks by putting them in this list. And I mean that handlers could be dynamically updated.
The key difference between a scheduler and the chore list is that every chore is given an type id that tells the kernel task scheduler( just though of that name!) that it should call or do this. For instance: It is sort of like a scheduler and cron combined, except it is integrated into the kernel (And optionally kernel modules.)

and what happens when it hits that 3 in your jobs list? your computer spends all of its time sorting the file system in memory until it's done, and then it returns to your apps? I'm still unclear as to the benefits.

I was just using that as an example, but I could make it so that every task is assigned an id and that every task is guaranteed to run for a maximum amount of time, the task is moved to up to the first empty task in the list and suspended. This is to guarantee the scheduler and processes some quantums. This system is like a kernel cron, and it will support repeating events.

Looks like a very simplistic FILO scheduler. The problem I have with it is that there is absolutely no way to prioritize any chore, and there is no way to guarantee something gets done in X amount of quantums. Thins like updating the screen need to happen at least a certain amount of times a second or the user will get choppy video, things like flushing a disk cache need to be a lower priority.

I also think its a very bad idea to separate kernel tasks from user tasks. Some kernel tasks need to always take priority over user tasks, while some don't need to happen at all, but can be a beneficial use to spare CPU time (e.g. zeroing page frames, defragmenting memory, etc). Since you would have to put all kernel tasks above user ones if you used two separate schedulers, so if you wish to do things like zeroing memory, you'll have bad situations where you've given CPU time to a thread that is zeroing memory, while a user task has work that needs to be run.

IMO, just create a range of priorities for kernel and user programs to use, and use that to schedule anything the kernel needs to get done. Cron's are completely outside the scope of a kernel scheduler, since AFAIK, the time resolution doesn't require it. You can easily have 100ms accuracy in userspace, which IMO is way more than enough for Cron's. I can't think of a reason why they would need to be implemented in kernel space, let alone a good enough one for it to outweigh the cons.

Example:
Priority 0-7: "Optional" kernel tasks
Priority 8-15: User tasks
Priority 16-23: Mandatory kernel tasks

You could even go a step further and do two sets of user priorities. One in which the program can set themselves, and one in which only the kernel can change.

^^^ more or less that

So this would be more efficient if I use priorities?
So it would look like this?
High Priority
-1-2-------------

User Scheduler: (Note these are PID's)
1-2-3-4--------

Low Priority
3456789485

do not confuse PID with process priority. PID is a unique number that works as a name for management. the process priority is a value a task is assigned(this can be changed on the fly) to determine what goes when and how often in the scheduler. UNIX nice command can set applications to have a priority in the scheduler. the value being how nice an application is about yielding to others, a low value being more important. for example a mission critical app that has a niceness of -20 would get first run of the processor(unless you have another -20 process competing with it).

logging into my server shows 3 PIDs that are not niceness 0
PID NICE
219 -4
293 -2
298 -2
all 3 being udevd stuff.

this should give you an idea on the subject.

Merlin: That is not what I meant, There are 3 seperate lists, High, Processes, and Low. Processes is just a list of pid's and is actually just used by the normal scheduler. In processes there will be a "niceness" factor called usage.
Berkus: Sorry, teenager+complex-os-stuff+midnight=confused and tired teen. Honestly, I don't know where cron came from.

Yes, For processes it's will be a priority round robin scheduler.
For the Kernel Task Scheduler, I just think it should be a First Come First Served scheduler. Tasks won't be rescheduled unless the repeat field in task_t is set to how many tasks up it should be scheduled to.

Lionel wrote:complex-os-stuff

Reading the tutorials aren't complex at all, coming up with your own ideas are even easier, and fun too. You have yet to know what "complex" really is.

VolTeK wrote:

Lionel wrote:complex-os-stuff

Reading the tutorials aren't complex at all, coming up with your own ideas are even easier, and fun too. You have yet to know what "complex" really is.

And

Lionel wrote:teenager+midnight

states why I said that.

But you do have a point. Actually, I am "refreshing" Chronos so that I use 95% my code, execpt for c++ loader.s and icxxabi. I do have some 'complex' ideas I'm thinking about for Chronos, but I'll never tell.

Lionel wrote:but I'll never tell.

I love surprises, i hate it when people go and list things they will never do. I believe your getting it