Discussion 3: The Cost of a Process

01 Overview

Course	COMP 3150 / CMIS 3150 — Operating Systems
Unit	Unit 3 — Processes
Weight	Part of the 5% participation grade (each discussion is worth approximately 0.4% of the final grade)
Opens	Monday of Week 3
Initial post due	Thursday of Week 3, 23:59
Peer replies due	Sunday of Week 3, 23:59
Format	One initial post (500–700 words, including at least one measured result) and at least two substantive peer replies (150–250 words each)
CLOs assessed	CLO2, CLO3, CLO6

Note on length and evidence

This discussion requires you to measure something and report the result. The initial post is slightly longer than the previous discussions because it must include the measurement data and the interpretation. You may include a small table or a short code listing, but the argument itself must be in prose.

02 Learning outcomes addressed

By participating in this discussion you will

Explain the process model, the process state model, and the contents of the process control block (U3.1, U3.2, U3.3).
Describe the role of the scheduler and the mechanism of a context switch (U3.4, U3.5).
Use Linux tools — /proc, time, perf, pidstat, and vmstat — to measure process-related costs (U3.4).
Interpret the measurements and explain them in terms of the process abstraction (U3.5).

This discussion assesses CLO2 (explain process and thread management), CLO3 (analyse scheduling), and CLO6 (apply Linux systems programming and tools).

03 Discussion prompt

Every process is an abstraction: the operating system presents each process with its own address space, its own registers, and its own view of the system. Maintaining that abstraction costs something. The costs are of three kinds:

Creation cost. fork() creates a new process; even with copy-on-write, it must duplicate the parent's page tables, copy the PCB, and allocate kernel data structures. exec() discards the old address space and loads a new one.
Context-switch cost. Switching between processes requires saving the outgoing process's registers, restoring the incoming process's registers, and updating the MMU's page-table base register. The direct cost is small (a few microseconds), but the indirect cost — TLB and cache pollution — can be much larger.
Termination cost. When a process exits, the kernel must release its resources, notify its parent, and (if the parent has already exited) reparent it to PID 1.

Your task

Choose one of the three costs above.
Design and run a small experiment on your Linux VM to measure that cost. Your experiment should be reproducible: state the commands you ran, the workload you used, and the conditions (for example, the number of iterations, the warm-up, the number of repetitions).
Report your measurements with the mean and (where appropriate) the standard deviation. Include a small table or a plot.
Interpret the measurements. What does the number tell you about the process abstraction? What are the sources of the cost? Which part is unavoidable, and which part is an artefact of the current implementation?
Compare your measurement with a published figure from the textbook or a paper. Are they in the same order of magnitude? If not, explain why (for example, different hardware, different kernel version, different workload).

Your post should be 500–700 words. Include the commands you ran and the results you obtained. Do not simply copy a figure from the textbook; measure it yourself.

04 Suggested experiments

You are free to design your own experiment. The following suggestions may help you get started.

4.1 Measuring creation cost

Write a small C program that loops N times, calling fork() and wait() each time. Measure the total elapsed time and divide by N. Repeat with fork() followed by exec() of a trivial program (/bin/true), and compare. Use clock_gettime(CLOCK_MONOTONIC) for the timing.

for (int i = 0; i < N; i++) {
    pid_t pid = fork();
    if (pid == 0) { _exit(0); }
    else { waitpid(pid, NULL, 0); }
}

Expect a few hundred microseconds per fork()+wait() on a modern system, and significantly more for fork()+exec(). Vary N (for example, 100, 1,000, 10,000) and plot the total time against N. The slope is the per-operation cost.

4.2 Measuring context-switch cost

Two approaches:

Microbenchmark. Write a program with two processes that communicate through a pipe. Each process writes a byte to the other and reads a byte back, in a loop of N iterations. Each round-trip involves at least two context switches (one to the other process, one back). Measure the total time and divide by 2N. Use sched_yield() or a pipe to force the switch.
System measurement. Use pidstat -w 1 or /proc/<pid>/status to read the voluntary and involuntary context-switch counts of a running process. Run a workload that blocks frequently (for example, cat on a large file) and one that is CPU-bound (for example, sha256sum on a large file), and compare the switch rates. Use vmstat 1 to observe the system-wide switch rate (cs column) and the run-queue length (r column).

Expect a direct context-switch cost of 1–5 microseconds on a modern system, but the indirect cost (cache and TLB pollution) can be much larger for a process with a large working set.

4.3 Measuring termination cost

Write a program that creates a child which exits immediately, and measure the time from fork() to the parent's wait() returning. Compare with the fork()+wait() time from § 4.1; the difference is the cost of the child's exit and the parent's reap. Also observe the zombie state: create a child that exits but is not immediately reaped, and use ps to observe the <defunct> state before the parent calls wait().

4.4 Tools and methodology

Warm up the cache before measuring. Run the experiment once and discard the result, then run it again for the measurement.
Repeat the measurement at least five times and report the mean and standard deviation. A single measurement is not evidence.
Use CLOCK_MONOTONIC for timing, not gettimeofday, because the latter is affected by clock adjustments.
Pin the process to a CPU with taskset to reduce variability, or at least note that you did not.
Report the kernel version (uname -r) and the CPU model (lscpu) with your result, because both affect the cost.

05 Grading rubric

The discussion is marked out of 100 points. The criteria and their weights are given below. The descriptors for each level are adapted to the measurement-based nature of this discussion.

Discussion 3 grading rubric — weights
Criterion	Weight
Post quality (including measurement rigour)	40%
Peer response quality	30%
Engagement and timeliness	20%
Netiquette and clarity	10%

5.1 Post quality (40 points)

Level	Descriptor
Exemplary (90–100%)	A clear, well-designed experiment that measures the chosen cost. The methodology is stated precisely (commands, workload, iterations, warm-up, repetitions). The results are reported with the mean and standard deviation. The interpretation is insightful: it explains the sources of the cost, distinguishes the unavoidable from the implementation-specific, and compares the result with a published figure. The commands are reproducible by a classmate.
Proficient (80–89%)	A well-designed experiment with a clear methodology. The results are reported with the mean. The interpretation is correct but does not distinguish the unavoidable from the implementation-specific, or does not compare with a published figure.
Developing (70–79%)	An experiment is run, but the methodology is incomplete (no warm-up, a single repetition, or no documentation of the hardware and kernel version). The interpretation is superficial.
Beginning (60–69%)	The experiment is not run, or the measurement is not reported. The post consists of a description of the cost without evidence.
Not demonstrated (<60%)	The post is missing, off-topic, or a restatement of the prompt without any measurement.

5.2 Peer response quality (30 points)

The descriptors are the same as for Discussion 1. In this discussion, an exemplary reply might:

Identify a methodological issue in the classmate's experiment (for example, a missing warm-up, or a confounding factor) and suggest a correction.
Compare the classmate's measurement with their own, and explain the difference in terms of hardware or workload.
Suggest an extension: a different workload, a different cost, or a different tool that would illuminate the result.

5.3 Engagement and timeliness (20 points)

The descriptors are the same as for Discussion 1.

5.4 Netiquette and clarity (10 points)

The descriptors are the same as for Discussion 1.

06 Resources

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 3 (Processes) and Chapter 4 (Threads and Concurrency).
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapters 4–6 (Processes, Process API, Direct Execution).
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 2 (Processes and Threads).
Love, R. Linux Kernel Development, 3rd ed., Chapter 3 (Process Management).
Linux man-pages: man 2 fork, man 2 execve, man 2 wait, man 2 clone, man 5 proc, man 1 pidstat, man 1 vmstat, man 1 perf.
Linux kernel documentation: Documentation/scheduler/ (scheduler design and statistics).
Gregg, B. Systems Performance, 2nd ed., Chapter 5 (Applications) and Chapter 6 (CPUs).
The bpftrace and perf tutorial material from Brendan Gregg's website: brendangregg.com.