Process Management in

Solaris

Introduction to Solaris

Developed in 1987 by AT&T and Sun Microsystems.

Compatible with SPARC architecture .

OpenSolaris was the Open Source version of the Solaris operating system
which has been discontinued after Oracle took over in 2010.

OS family: Unix

Programmed in : C

Default UI: GNOME

Mixed Source- Only certain features are open source.

Process

The most basic abstraction provided by an Operating System.

A process is an executable object located at physical memory pages.

Every process has its own unique integer number called Process ID.

Solaris Kernel Threads

A thread is an independent flow of control that operates within the same

address space as other independent flows of control within a process.

Solaris is a multi-thread Operating System, that is every task performed is

executed like a kernel thread.

On a single processor, multithreading is generally implemented by timedivision multiplexing (as in multitasking): the processor switches between
different threads. This context switching generally happens frequently enough
that the user perceives the threads or tasks as running at the same time.

On a multiprocessor or multi-core system, threads can be truly concurrent,

with every processor or core executing a separate thread simultaneously.

Advantages of Threads in Solaris

The main benefit of threads (as compared to multiple processes) is that the
context switches are much cheaper than those required to change current
processes.

Even within a single-processor environment, multiple threads are

advantageous because one thread may be able to progress even though
another thread is blocked while waiting for a resource.

Threads also have private resources (program counter, stack, register context,
etc).

Lightweight Processes

A lightweight process can be considered as the swappable portion of a kernel

thread. A light-weight process (LWP) is a means of achieving multitasking.

A LWP runs in user space on top of a single kernel thread and shares its
address space and system resources with other LWPs within the same process.

Zombie Processes

When a process dies, it becomes a zombie process. A zombie process or

defunct process is a process that has completed execution but still has an
entry in the process table.

Normally, the parent performs a wait() and cleans up the PID.

Killing the parent or rebooting will also clean up zombies.

The correct answer is to fix the buggy parent code that failed to perform the
wait() properly.

Managing System Processes

ps- checks status of all active processes. The following information is reported when the ps
command is executed.

Current status of the process

Process ID

Parent process ID

User ID

Scheduling class

Priority

Address of the process

Memory used

pldd- Lists the dynamic libraries that are linked into a process

pmap- Prints the address space map of each process

pstop- stops the process

pwdx- Displays the current working directory for a process

ptree- Displays the process trees that contain the process

pkill- To kill a process in case it gets stuck in an infinite loop

Process Scheduling-Priority Model

The Solaris kernel is fully preemptible. This means that all threads,
including the threads that support the kernel's own activities, can be
deferred to allow a higher- priority thread to run.

Solaris recognizes 170 different priorities, 0-169, with 169 being the
largest/highest priority. Within these priorities fall a number of
different scheduling classes.

Scheduling classes in Solaris

TS (timeshare): This is the default class for processes and their

associated kernel threads. Priorities within this class range 0-59, and
are dynamically adjusted in an attempt to allocate processor
resources evenly.

IA (interactive): This is an enhanced version of the TS class that

applies to the in-focus window in the GUI. Its intent is to give extra
resources to processes associated with that specific window. Like TS,
IA's range is 0-59.

FSS (fair-share scheduler): This class is share-based rather than

priority- based. Threads managed by FSS are scheduled based on their
associated shares and the processor's utilization. FSS also has a range
0-59.

FX (fixed-priority): The priorities for threads associated with this

class are fixed. (In other words, they do not vary dynamically over the
lifetime of the thread.) FX also has a range 0-59.

SYS (system): The SYS class is used to schedule kernel threads.

Threads in this class are "bound" threads, which means that they run
until they block or complete. Priorities for SYS threads are in the 6099 range.

RT (real-time): Threads in the RT class are fixed-priority, with a fixed

time quantum. Their priorities range 100-159, so an RT thread will
preempt a system thread. Real time processes cannot be preempted
by any other process, therefore it usually requires administrative
privileges to run. It is normally not advisable to create a RT process.

Implementation of Time Slicing for TS

and IA

TS and IA scheduling classes implement an adaptive time slicing

scheme that increases the priority of I/O-bound processes at the
expense of compute-bound processes. The exact values that are used
to implement this can be found in the dispatch table.

To examine the TS dispatch table, run the command

dispadmin -c TS -g.

The following values are reported in the dispatch table:

ts_quantum: This is the default length of time assigned to a process with the
specified priority.

ts_tqexp: This is the new priority that is assigned to a process that uses its
entire time quantum.

ts_slpret: The new priority assigned to a process that blocks before using its
entire time quantum.

ts_maxwait: If a thread does not receive CPU time during a time interval of
ts_maxwait, its priority is raised to ts_lwait.

Modifying the dispatch table

dispadmin can be used to edit the dispatch table to affect the decay of
priority for compute-bound processes or the growth in priority for I/O-bound
processes.

In particular, ts_maxwait and ts_lwait can prevent CPU starvation, and

raising ts_tqexp slightly can slow the decline in priority of CPU-bound
processes.

In any case, the dispatch tables should only be altered slightly at each step in
the tuning process, and should only be altered at all if you have a specific
goal in mind.

The following are some of the sorts of changes that can be made:

Decreasing ts_quantum favors IA class objects.

Increasing ts_quantum favors compute-bound objects.

ts_maxwait and ts_lwait control CPU starvation.

ts_tqexp can cause compute-bound objects' priorities to decay more or less

rapidly.

ts_slpret can cause I/O-bound objects' priorities to rise more or less rapidly.

Time Slicing for FSS

In FSS, the time quantum is the length of time that a thread is allowed to run
before it has to release the processor. This can be checked using
dispadmin
-c FSS -g

The QUANTUM is reported in ms. (The output of the above command displays
the resolution in the RES parameter. The default is 1000 slices per second.) It
can be adjusted using dispadmin as well.

Thundering Herd

When a resource is freed, all threads awaiting that resource are

woken. This results in a footrace to obtain access to that object; one
succeeds and the others return to sleep(blocked state). This can lead
to wasted overhead for context switches. This is called a "thundering
herd" problem.

Issues with Real Time processes

Real time processes also lock all their pages in memory. This can cause
problems on a system that is underconfigured for the amount of memory that
is required.

Since real time processes run at such a high priority, system daemons may
suffer if the real time process does not permit them to run.

When a real time process forks, the new process also inherits real time
privileges. The programmer must take care to prevent unintended
consequences. Loops can also be hard to stop, so the programmer also needs
to make sure that the program does not get caught in an infinite loop.

References

www.docs.oracle.com

www.princton.edu