schedpong - scheduler pong
schedpong forks a number of processes that do different kinds of work. This can be used to evaluate the behavior of your scheduler under different conditions.
There are three kinds of jobs in schedpong:
A thinker job is one CPU-bound process: it loops computing and doesn't sleep for I/O or use much memory.
A grinder job is one memory-bound process: it loops accessing lots of memory, similar to the various VM stress tests.
A pong group job is a family of I/O-bound processes. An arbitrary number of processes play scheduler pong using the user semaphores (semfs), each process signalling the next.
By choosing different numbers of thinkers, pong groups, and grinders, and adjusting the pong group size, one can evaluate how well a scheduler does under different conditions. In general schedulers should be favoring the pong groups in order to minimize the response latency of the semaphore ponging, but without starving the thinkers. Adding grinders to the mix lets your deal with what happens when you also have swapping going on, which is a complicated situation not handled well by textbook algorithms.
Note that you need to have a real VM system (not dumbvm) to use grinders. With dumbvm you may also need to configure a fair amount of memory to get all the intended processes to fork successfully.
schedpong uses the following system calls:
However, note that schedpong relies heavily on the user semaphores; if they do not work (owing e.g. to bugs in open/read/write) schedpong will not work either. Make sure usemtest runs (at least up to the "shoot" test, even if that part doesn't) before spending time on schedpong.
schedpong without grinders should work once you have implemented the basic system calls and they work reliably (particularly fork). schedpong with grinders should work once you have implemented the sbrk system call and a virtual memory system that supports dynamic memory allocation.