Thread-Level Parallelism - Computer Architecture: A Quantitative Approach - page 409

FIGURE 5.33 The performance/cost relative to a 4-processor system for three bench-
marks run on an IBM eServer p5 multiprocessor containing from 4 to 64 processors
shows that the larger processor counts can be as cost effective as the 4-processor
configuration . For TPC-C the configurations are those used in the official runs, which means
that disk and memory scale nearly linearly with processor count, and a 64-processor machine
is approximately twice as expensive as a 32-processor version. In contrast, the disk and
memory are scaled more slowly (although still faster than necessary to achieve the best
SPECRate at 64 processors). In particular, the disk configurations go from one drive for the
4-processor version to four drives (140 GB) for the 64-processor version. Memory is scaled
from 8 GB for the 4-processor system to 20 GB for the 64-p-rocessor system.
Pitfall Not Developing The Software To Take Advantage Of, Or Optimize For, A
Multiprocessor Architecture
There is a long history of software lagging behind on multiprocessors, probably because the
software problems are much harder. We give one example to show the subtlety of the issues,
but there are many examples we could choose from!
One frequently encountered problem occurs when software designed for a uniprocessor is
adapted to a multiprocessor environment. For example, the SGI operating system in 2000 ori-
ginally protected the page table data structure with a single lock, assuming that page alloc-
ation is infrequent. In a uniprocessor, this does not represent a performance problem. In a
multiprocessor, it can become a major performance botleneck for some programs. Consider a
program that uses a large number of pages that are initialized at start-up, which UNIX does