|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
| Old News | Recommended Books | Recommended Links | Reference | shmmax | The Unix File system |
A process is an "invocation" or "activation" of a program. A program is a list of instructions for execution by a computer. A program may be stored in any convenient form including handwritten notes on pieces of paper but is most commmonly stored in binary form in a file. To run the program it needs to be copied (or loaded) into the main computer memory and the central processing unit told to start reading (and obeying) instructions taken from that area of memory. The acitvity of executing the program's instructions is called running the process.
It will be seen that a potion of memory needs to be allocated to a process. The actual allocation of such an area of memory is a task for the loader. The memory area allocated to a program will usually be split into several sub-areas for particular.
This holds the data being processed by the program, it's size is initially determined by the loader from information in the binary file which specifies the amount of initialised data to be copied form the binary file and the amount of uninitialised space to be allocated to the process. On some systems the space may be initialised to zero but this is not universal and such areas may contain "droppings" left over from previous processes, a possible security problem. On older Unix systems the uninitialised space is known as bss from a PDP/11 assembler mnemonic.
The Unix size command will give the memory requirement information for a binary file.
bash$ size testhand2 92763 + 7564 + 2320 = 102647
The above example shows that loading the binary file testhand2 will require 102647 bytes of memory with 92763 bytes for code, 7564 bytes for initialised data and 2320 bytes for non-initialised data.
All modern processors expect programs to be built out of functions and procedures. Whenever a function is called a stack frame is created to store data related to the current invocation of the function such as the return address, saved state, local copies of parameters and, of course, local data. The stack is normally built within the data area of the process and the memory allocated to the stack can be expanded as needed.
Dynamic memory allocation as supported by functions such as malloc will normally be in a separate area of memory known as the arena or the heap. It is also part of the processes data area and also expands as required.
The stack and the arena need to be kept separate from the initialised and uninitialised data areas, this is normally achieved by using widely separated parts of a large virtual address space.
A system call is a function like mechanism whereby a process can request services from the kernel. A system call includes a special instruction which causes a software interrupt (sometimes called a trap), responding to this interrupt switches the processer into kernel or priviliged mode whilst maintaining the process identity. The response also involves switching the stack pointer to the kernel stack so that any kernel functions that are called in response to the system call will use the kernel stack rather than the user stack.
It is interesting to note the overheads associated with handling a disc transfer completion interrupt are "charged" to the process that happens to be running when the interrupt occurs.
There will, inevitably, be a significant amount of information about a process that is only relevant to the kernel. This will include data such as the process user-id (for access rights checks), pointers to open file information blocks, saved register states for processes not currently running, process "environment" etc., etc. Some of this information is stored in an entry in the process table which has an entry for every current process and some is stored in a per-process memory area called the u_area on Unix systems.
The following diagram shows the interaction of the various memory areas for a Unix process.
Details of the structure of a process table entry may be found in the file /usr/include/sys/proc.h and the u_area in the file /usr/include/sys/user.h.
Processes can only be created by the system call fork(), apart from process 1 which is "hand-crafted" at boot time and is the ultimate parent of all other processes. Once a process has been created it can be in various states as shown in the following diagram (based on Bach).
A freshly created process. Whether freshly created processes are entirely resident in memory depends on the details of the memory management system. This state may also include processes that have not yet been fully created.
There is no reason why the process should not run apart from the fact that some other process is currently running.
The process is running in kernel mode. It may be handling a system call or an interrupt or some other process (also in kernel mode) may have scheduled it to run. The process may determine that it has finished (either normally via an exit() or via some kernel detected abnormal condition) or that it is blocked awaiting some event such as a time signal or peripheral activity.
The normal state.
The process has been interrupted and is about to resume normal user mode operation. The kernel scheduler may move a process into this state.
The process will not run again but information, such as the exit code, has not been collected by the parent process so a process table slot is still required to store this information.
The process is blocked awaiting an event. All that can happen is that the process can be woken up (by changing its status to "ready to run") or swapped out.
The process is waiting for an event (details in the process table entry for the process) and has been swapped out.
Before running the process needs to copied back in to memory.
The Unix operating system supports a number of standard commands for determining information about the processes currently running on a computer. The most commonly used is undoubtedly 'ps', unfortunately this is one of the Unix commands that come in two flavours, one system V derived and one BSD derived. Which flavour you get when you type "ps" depends on your search path.
Here's some typical output from the BSD variant.
# ps -aguwwx | head -10 USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND root 12885 8.4 0.8 2152 1960 pts/0 O 15:18:19 0:01 ps -aguwwx root 3 1.3 0.0 0 0 ? S Aug 12 1191:52 fsflush ftp 12881 0.5 0.6 1884 1444 ? S 15:18:13 0:00 in.ftpd -l root 173 0.5 18.04866845928 ? S Aug 12 265:51 /usr/sbin/in.named root 134 0.4 0.5 5248 1184 ? S Aug 12 611:21 /usr/multicast/mrouted root 12884 0.2 0.2 744 528 pts/0 S 15:18:19 0:00 head -10 nobody 12751 0.2 0.9 3032 2208 ? S 15:14:47 0:00 /appsy/apache_1.3.3/src/httpd -f /appsy/apache_1.3.3/etc/httpd.conf nobody 12238 0.2 0.9 3032 2220 ? S 14:59:11 0:01 /appsy/apache_1.3.3/src/httpd -f /appsy/apache_1.3.3/etc/httpd.conf nobody 12695 0.2 0.9 3032 2224 ? S 15:12:38 0:00 /appsy/apache_1.3.3/src/httpd -f /appsy/apache_1.3.3/etc/httpd.conf
The listing is in CPU usage order and has been trimmed to show the 10 most CPU intensive processes. Most of the column headings are fairly obvious, "SZ" is the combined size of the data and stack segments (in kbytes), "RSS" is the real memory used by the process. Some interesting points to note from the listing above.
For more information about processes the ps command may be used with the -l flag (meaning long listing), the processes are no longer listed in CPU usage order.
# ps -aglwx | head -15 F UID PID PPID CP PRI NI SZ RSS WCHAN S TT TIME COMMAND 19 0 0 0 0 96 0 0 0 T ? 0:00 sched 8 0 1 0 0 58 20 1572 100 ufstrans S ? 25:02 /etc/init - 19 0 2 0 0 98 0 0 0 push_cv S ? 0:54 pageout 19 0 3 0 1 60 0 0 0 fsflush_ S ? 1242:51 fsflush 8 0 19 390 0 0 0 0 Z 0:008 0 131 1 0 58 20 1312 168 clnt_max S ? 5:04 /usr/sbin/in.rdisc -s 8 0 134 1 1 58 20 5248 1120 zscom S ? 637:17 /usr/multicast/mrouted 8 0 139 1 0 58 20 2248 680 zscom S ? 952:34 /usr/sbin/rpcbind 8 0 141 1 0 58 20 1568 476 zscom S ? 289:10 /usr/sbin/keyserv 8 0 147 1 0 58 20 1800 640 zscom S ? 1:14 /usr/sbin/nis_cachemgr 8 0 149 1 0 31 20 1716 4 zscom S ? 0:00 /usr/sbin/kerbd 8 0 173 1 0 58 204866845328 zscom S ? 280:57 /usr/sbin/in.named 8 0 178 1 0 58 20 1764 524 zscom S ? 3:21 /usr/sbin/inetd -s 8 0 181 1 0 59 20 1964 412 zscom S ? 0:07 /usr/lib/nfs/statd
This shows scheduling information (PRI (priority), NI (niceness) and CP (short-term CPU utilisation)), the nature of the event the process is waiting for (WCHAN) and process flags (F).
For full details consult the manual pages for the BSD version of ps and the System V version of ps. For more detailed and specialist information see the vmstat command.
When there are several runnable processes available, the next one to be run will usually be selected on a priority basis. The prioirty is a function of the process history and a user manipulable parameter known as the niceness of the process, the higher the niceness, the lower the priority, the highest value is 20.
The command priocntl can be used to manipulate priorities. The command nice can be used to launch a process at a specified priority and renice can be used to modify the niceness of an existing process. Unless you are super-user you can only decrease the niceness of a process.
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: August 12, 2009