Thrashing and Working Sets
Lecture Notes for CS 140
Spring 2014
John Ousterhout
- Readings for this topic from Operating Systems: Principles and Practice:
Section 9.7.
- Normally, if a thread takes a page fault and must wait for
the page to be read from disk, the operating system runs
a different thread while the I/O is occurring.
Thus page faults are "free"?
- What happens if memory gets overcommitted?
- Suppose the pages being actively used by the current
threads don't all fit in physical memory.
- Each page fault causes one of the active pages to be
moved to disk, so another page fault will occur soon.
- The system will spend all its time reading and writing
pages, and won't get much work done.
- This situation is called thrashing; it was a
serious problem in early demand paging systems.
- How to deal with thrashing?
- If a single process is too large for memory, there is
nothing the OS can do. That process will simply thrash.
- If the problem arises because of the sum of several
processes:
- Figure out how much memory each process needs to prevent
thrashing. This is called its working set.
- Only allow a few processes to execute at a time, such that
their working sets fit in memory.
- Page fault frequency: one technique for computing working sets
- At any given time, each process is allocated a fixed
number of physical page frames (assumes per-process
replacement).
- Monitor the rate at which page faults are occurring
for each process.
- If the rate gets too high for a process, assume that
its memory is overcommitted; increase the size of its
memory pool.
- If the rate gets too low for a process, assume that
its memory pool can be reduced in size.
- Scheduling with working sets
- If the sum of all working sets of all processes
exceeds the size of memory, then stop running some
of the processes for a while.
- Divide processes into two groups: active and
inactive:
- When a process is active its entire working set
must always be in memory: never execute a thread
whose working set is not resident.
- When a process becomes inactive, its working set
can migrate to disk.
- Threads from inactive processes are never scheduled
for execution.
- The collection of active processes is called the
balance set.
- The system must have a mechanism for gradually moving
processes into and out of the balance set.
- As working sets change, the balance set must be adjusted.
- None of these solutions is very good:
- Once a process becomes inactive, it has to stay inactive
for a long time (many seconds), which results in poor response
for the user.
- Scheduling the balance set is tricky.
- In practice, today's operating systems don't worry much
about thrashing:
- With personal computers, users can notice thrashing and
handle it themselves:
- Typically, just buy more memory
- Or, manage balance set by hand
- Memory is cheap enough that there's no point in operating a
machine in in a range where memory is even slightly overcommitted;
better to just buy more memory.
- Thrashing was a bigger issue for timesharing machines
with dozens or hundreds of users:
- Why should I stop my processes just so you can make
progress?
- System had to handle thrashing automatically.