Should a scheduler give timeslices?

[nexos]

Hello,
I am making a scheduler. It is currently a simple round robin that just increments a task pointer. My previous ones were terrible, so I am going to slower and doing it the right way. I was wondering if a task switch should occur every tick, or every 3 ticks or so. Brokenthorn, and fair amount of OSes on this community give each task one tick and move to the next. It is simple, but is it any good?
Thanks,
nexos

[foliagecanine]

Define tick. 100us? 1ms? 10ms?
For a pure round-robin, all tasks would get an equal amount of timespace.

From what I can tell, generally it is preferred to at least have some sort of priority system.
For example, you can set the priority level to be the amount of ticks the process gets before it switches.

I haven't work on my scheduler that much for a while, but my task switch routine is called once every millisecond.
I doubt that's a good way to do it, but as I said, I haven't worked on it for a while.
(I also neglected to write any way to have kernel multitasking, which I should fix soon)
Additionally, any task can call a "yield" syscall and prematurely give up their timeslice.
This is very helpful for polling processes, such as my shell, which is constantly checking for keyboard input.

[alexfru]

generally it is preferred to at least have some sort of priority system.
For example, you can set the priority level to be the amount of ticks the process gets before it switches.

Normally, priority means you do some things before other things. Which in its purest form means that it's preemptive w.r.t. priority levels, i.e. that unless there's nothing to do at priority level N, you can't execute anything from lower priority levels N+1, N+2, etc (assuming lower Ns mean higher priority and higher Ns mean lower priority) and that if a higher priority task becomes runnable, you have to preempt all others and run it.

This purest/strictest form has disadvantages. For example, low priority tasks may starve if there's always something at higher priority levels, for which reason they may be given a chance to run once in a while anyway (e.g. in Windows). Also, it may lead to worse UX in UI and such, for which reason it's common to temporarily increase/boost the priority of the tasks whose UI controls are being manipulated by the user (also in Windows). See also priority inversion.

[thewrongchristian]

Hello,
I am making a scheduler. It is currently a simple round robin that just increments a task pointer. My previous ones were terrible, so I am going to slower and doing it the right way. I was wondering if a task switch should occur every tick, or every 3 ticks or so. Brokenthorn, and fair amount of OSes on this community give each task one tick and move to the next. It is simple, but is it any good?
Thanks,
nexos

Why not it a variable in the task control block, indicating how many timeslice ticks the scheduler has given it?

Then, each tick, decrement the variable in the current task, and reschedule when it reaches 0.

That way, you can separate the mechanism of timeslice length handling from the policy of setting the timeslice length.