Solaris 2

Numerous substantial changes were made in the Solaris 2 scheduler. Part of them made the scheduling simpler and more easily tunable. The end result was a table-driven scheduler and the capability for administrators to completely confuse the entire system by loading their own tables. The table construction is not complex, but you should be careful about making major changes blindly. If you are analyzing a system that is performing strangely, it might be worthwhile verifying that the tables are still the originals .

Scheduling is now performed on a thread basis rather than on a process basis. This allows different threads of control within the same process to be run independently and with unique priorities.

Threads will also have scheduling classes associated with them. Each scheduling class has its own set of parameter tables to control dispatching and its own kernel code to process them. The normal class for user processes is "timeshare," but there is now a real-time scheduling class available. Real-time threads have a higher precedence than any other thread on the system except for interrupt service routines. Real-time will also take priority over system daemons and internal kernel threads. If a real-time process gains control, particularly in a single processor system, and gets into a loop, the only solution may be to halt and reboot the machine. (This is one easy thing to look for when debugging a hung system: Make sure no user processes running with real-time priorities have taken over the machine.)

There are now 170 possible priorities (dispatch queues), of which 60 are given to timeshare threads, 40 are allocated for kernel operations, 10 are reserved for interrupt services, and the remaining 60 are available for real-time work. The same basic functions must be performed as in the 4.x kernel, so swtch() and resume() are still around to do the actual thread selection and thread startup. Some new functions manipulate the dispatch queues, based on the parameter tables defining the class characteristics (for both timeshare and real time). The tables are the most important part; they specify what queue a thread will move to for its next turn to run.

For timeshare threads, the dispatch parameter table contains several columns :

• A priority (queue) number

• A time quantum in milliseconds ( ranging from 10 to 100)

• The queue a thread is moved to if it uses up all its time

• The revised priority of a thread if it hasn't used up its time (and thus deserves a better shot next time)

• The amount of time remaining in which to try to use up that quantum (typically 5 seconds)

• The priority temporarily assigned to the thread after it returns from a sleep. Generally, the priority is higher than normal to allow a thread that was waiting for I/O to complete to get in promptly and use that data. This gives interactive processes a slightly better response time.

Real-time threads are controlled by a much simpler parameter table, because a priority for real-time is usually based on the job a thread has to do rather than the amount of time it has used up. These threads do not change priorities; their table contains a time quantum and that's about all. This allows multiple threads at the same real-time priority level to cycle among themselves until they're finished, sleeping, or a higher-priority task comes along.

Along with the tables defining general class characteristics, every thread has associated with it a scheduling class structure, which contains information used by the appropriate scheduling functions to help identify the proper dispatch queue. This information includes the current priority numbers , nice value, amount of time left in this thread's quantum, and various flags. Look in /usr/include/sys for ts.h and rt.h to find the scheduling class structure definitions for timeshare and real-time threads.

The internal kernel threads, such as the page daemon, the STREAMS service procedures, and the NFS daemons, also have a scheduling class, which is really just timeshare with a slightly higher priority setting. These system threads run at a priority above normal timeshare users, but below real-time.

In Solaris 2, interrupts have scheduling priority levels as well. Interrupt processing is more sophisticated; there is a separate thread for most interrupt priority levels, so a service routine may actually sleep and wait for some busy resource. This means that interrupt handlers can be scheduled and thus need a set of queues for their own use. These are always the highest-priority threads on the system.