Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Processes

Old News Recommended Books Recommended Links Reference shmmax The Unix File system  

Old News ;-)

Basics

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.

The code area

This is known as the text area in Unix parlance and simply contains the executable code of the program. If there are several processes running the same program there will still only be one code area as it is identical for all processes. The current state of a process is determined by its various data areas. The kernel process exchange (or switch) mechanism will activate a particular process by indicating to the hardware

The data area

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.

The stack area and the arena

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.

System calls

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.

Process Information

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.

Process states

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).

As shown above, aprocess can be in any one of nine distinct states.
  1. Created

    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.

  2. Ready to run, in memory

    There is no reason why the process should not run apart from the fact that some other process is currently running.

  3. Running in kernel mode

    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.

  4. Running in user mode

    The normal state.

  5. Pre-empted

    The process has been interrupted and is about to resume normal user mode operation. The kernel scheduler may move a process into this state.

  6. Zombie (or defunct)

    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.

  7. Sleeping in memory

    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.

  8. Sleeping, swapped out

    The process is waiting for an event (details in the process table entry for the process) and has been swapped out.

  9. Ready to run, swapped out

    Before running the process needs to copied back in to memory.

The concept of swapping implies that the entire memory image of a process is moved between backing storage (disc) and memory. Modern systems still maintain copies of process images in the swapping area but dynamic paged memory management automatically deals with the issues of moving page images between backing store and main memory resulting in a blurring of the distinction between "swapped out" and "in memory" processes.

Process Information

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:00  
 8     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.

Scheduling and Priorities

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.



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: August 12, 2009