OSDev.org

I couldn't think of a good way to phrase the title, but I'm going to implement multiprocessing in my operating system. Every certain time period, I need some kernel code to run to switch which process is currently running. I assume a good way of doing this would be setting up a timer such as the PIT, and then switch processes whenever that interrupts. Is this an acceptable way of doing this?

It's more normal to count a number of ticks before switching, rather than switching on every interrupt. Apart from anything else this allows flexibility in how often the switches occur. And you'll want a clock that has finer granularity than task switches for other timing tasks. You'll also, probably, want to implement different priorities so that some processes get more CPU time than others.

Don't forget the case where there are no other processes ready to run. And think about the possibility that no process is ready to run.

"Priorities" are usually used in a real-time scenario, where the highest-priority thread always gets to run. Giving some processes longer time slices then others does not seem to be that useful to me: it would only matter if there are multiple non-interactive ("batch" / compute-heavy) tasks and running many of those is an uncommon workload (AFAICT). What's far more common is just limiting the CPU time that a certain set of processes can get per second (I am thinking of cgroups and containers).

Regarding the length of time slices: that greatly varies among OSes. Some OSes have fixed time slices (Linux before 2.6.23), say 1/100 s or 1/1000 s. Other OSes (modern Linux, managarm - shameless self promotion) use tickless systems that adjust the length of a time slice such that every thread gets roughly 1/T of a second - regardless of the number of threads running. In particular, for those systems, the length of a time slice depends on the number T of active threads and on the "unfairness" introduced by earlier scheduling decisions.

I liked priorities. I didn't make much use of them, of course, but I did start whole-system compilation with a lower priority so it wouldn't interfere with me playing a CPU-intensive game. It didn't make a big difference, but it was nice. If I didn't want to play that game the low-priority processes could still get all the CPU time, which wouldn't be the case if there was a fixed limit on the time they could get.

I didn 't see any particular increase or decrease in subjective quality when Linux went tickless. For my usage, (web, game, compiling,) it was fine both ways. I don't think I tested it as carefully as I did faster ticks and preemptable kernel.

Tickless is mostly a power management thing, so you'd only notice with light use on a laptop in battery mode that it lasts longer. See, with a ticking system, the system is waking up every tick even when there is nothing to do. With tickless, in many circumstances the system is only woken by the next real interrupt. The usefulness of this depends on how many ticks would go by without anything to do. The problem here is that some peripherals require periodic updates, anyway (USB HIDs come to mind), so you've only replaced one timer with another.

Out of the USB HCDs, only the old UHCI needs periodic updates (and possibly OHCI, I don't know much about the latter).