Scheduler tutorial

[mariuszp]

I wrote a scheduler tutorial a minute ago, and I want you guys to check it out before it gets posted on the tutorials page. I can't really judge if it's for beginners or experts, I tried making it simple though
https://wiki.osdev.org/User:Mariuszp/Scheduler_Tutorial

[bluemoon]

It seems that the tutorial is focused at a specific implementation instead of general schedule ideas.
It can be misleading as if paging, PIT, COM were required for multi-tasking (and they are not).

If you don't use paging, you can't load more than 1 COM file at once, so this tutorial will be useless, unless you can load other formats.

No. paging is a policy for managing memory resource, while you can loading more than one COM file without paging, they do not have dependency.

You must have PIT support.

No. It's not a must. You may use APIC timer, or even no timer (ie. by hot key to switch task, or switch task upon syscall, or have application actively call yield())

The remaining document seems nice, but too focus on your choice of implementation.
I suggest to re-phase the tutorial as an example implementation, and avoid confusing reader with requirement of your implementation and requirement of general concept on multi-tasking.

[Combuster]

It seems that the tutorial is focused at a specific implementation

Isn't that what a tutorial is meant to do? To teach you the concept by using an example?

I do have some different problems with that page: it should concern scheduling but focuses in text size more on dealing with .COM files which are not .COM files (they require 16-bit real mode, not 32-bit protected mode. Which makes your tutorial one to fear as it is factually wrong).
Subject wise, it often does not explain design choices and how they map to general scheduling theory. It does not contain an operational example, just some fragments with a lack of the complete picture. In essence, your "tutorial" looks more like a regular wiki page, which explains bluemoon's comments.

In other words, it's not a tutorial, its not an article, it's basically an unfinished prototype that needs some work before it can turn into something useful. I suggest you move it to your userspace (like User:mariuszp/Scheduler_Tutorial) and keep working on it.

[jnc100]

You appear to be combining multiple concepts into a tutorial about a specific concept. Your tutorial currently includes a basic implementation of a scheduler using a linked list, a task switch mechanism and a program loader. I suggest you either rename it to, for example, Multitasking tutorial and provide a basic broad overview of implementation of multitasking or focus specifically on the scheduler implementation, which IMHO should include:

- Implementation using a linked list or more advanced structures e.g. a delta list
- Ability to add and remove tasks from the list
- Ability for a task to sleep for a certain amount of time - either that amount of time as accurately as possible or 'at least' that amount of time depending on the design of the reader's system
- Ability for a task to sleep awaiting an interrupt or message
- Ability to select the next task to execute based on either a message from the timer or when another task yields, and then hand this information to the task switcher
- Optionally implementation of processor affinity for the more advanced readers
- Optionally using threads as the basic unit in the scheduler rather than processes

Please note the distinction - the platform-independent scheduler selects what task should be running currently, the platform-specific task switcher actually does the switch of registers and address spaces.

And the above should be able to be done platform independently. Obviously as you're writing a tutorial you could also include, for example, a basic task switcher using x86 code, probably avoiding fpu/sse saves as these add unnecessary complexity to the tutorial.

Otherwise please continue the good work - I suppose my main problem with it as it stands as it is not exactly clear what concepts you are trying to cover.

Regards,
John.

[gravaera]

Yo:

You must have PIT support

Should be, "You must have support for a usable timer": there are multiple reliable periodic IRQ source on the PC

This can be done automatically (multi-tasking) or at the user's demand.

"This can be done via intervention from the kernel, or by trusting userspace to fairly relinquish CPU time. The former is 'pre-emptive' multitasking and the latter is 'co-operative' multitasking."

Any scheduler which can run multiple tasks side by side and manage them so that they do not have to be done in an "batch" style is a multi-tasking scheduler. Old machines were "single process"; then came "batch processing", and eventually "multitasking and time sharing"

Things to consider adding:

• Consider mentioning things like the goals a scheduler may have. For example, some schedulers may be designed to ensure that "high priority" tasks are always going to be treated as such, and given pride of place in scheduling. Other schedulers are designed to prioritize fairness. Other schedulers are designed to meet real-time constraints.
• Propose some theory that would demystify the idea of "priorities" in a scheduler to a newcomer. Mention things that would let them think a bit more aggressively when designing, such as the need to cater for soft real-time scheduling for audio and video applications in desktop kernels, and how priorities can help with that.
• Ensure that the reader understands the differences in scope and responsibility between the timer subsystem and the scheduling subsystem, even though they are tightly coupled.
• Tie in broader examples in a more general sense. For example, instead of recommending "PIT support", or "LAPIC local timer support", speak more broadly about the uniprocessor scheduler era, and the multiprocessor scheduler era, and how contemporary scheduler timers have changed in source and location. (From being a single chip on the chipset, to being moved into each logical CPU to give each CPU its own local periodic scheduler IRQ source). The current revision of the article won't help the user to understand how to scale periodic timer IRQs to the SMP case.
• Unify scheduling theory with locking theory in an offhanded manner so that semaphores/mutexes can be brought into perspective.
• Other things which add more body to the theory behind scheduling.

Focus less on code; it limits the reader's mind, imagination, and understanding. Try to throw ideas at them and let them get out a pencil and paper and think instead.