Estimating resources required by a new program
The invention and redesign that take place during the coding phase defy prediction, but the following guidelines can help you to get a general sense of the requirements.
It is impossible to make precise estimates of unwritten programs. As a starting point, a minimal program would need the following:
- About 50 milliseconds of CPU time, mostly system time.
- Real Memory
- One page for program text
- About 15 pages (of which 2 are pinned) for the working (data) segment
- Access to libc.a. Normally this is shared with all other programs and is considered part of the base cost of the operating system.
- About 12 page-in Disk I/O operations, if the program has not been compiled, copied, or used recently. Otherwise, none required.
To the above, add the basic cost allowances for demands implied by the design (the units given are for example purposes only):
- CPU time
- The CPU consumption of an ordinary program that does not contain high levels of iteration or costly subroutine calls is almost immeasurably small.
- If the proposed program contains a computationally expensive algorithm, develop a prototype and measure the algorithm.
- If the proposed program uses computationally expensive library subroutines, such as X or Motif constructs or the printf() subroutine, measure their CPU consumption with otherwise trivial programs.
- Real Memory
- Allow approximately 350 lines of code per page of program text, which is about 12 bytes per line. Keep in mind that coding style and compiler options can make a difference of a factor or two in either direction. This allowance is for pages that are touched in your typical scenario. If your design places infrequently executed subroutines at the end of the executable program, those pages do not normally consume real memory.
- References to shared libraries other than libc.a increase the memory requirement only to the extent that those libraries are not shared with other programs or instances of the program being estimated. To measure the size of these libraries, write a trivial, long-running program that refers to them and use the svmon -P command against the process.
- Estimate the amount of storage that will be required by the data structures identified in the design. Round up to the nearest page.
- In the short run, each disk I/O operation will use one page of memory. Assume that the page has to be available already. Do not assume that the program will wait for another program's page to be freed.
- Disk I/O
- For sequential I/O, each 4096 bytes read or written causes one I/O operation, unless the file has been accessed recently enough that some of its pages are still in memory.
- For random I/O, each access, however small, to a different 4096-byte page causes one I/O operation, unless the file has been accessed recently enough that some of its pages are still in memory.
- Each sequential read or write of a 4 KB page in a large file takes about 100 units. Each random read or write of a 4 KB page takes about 300 units. Remember that real files are not necessarily stored sequentially on disk, even though they are written and read sequentially by the program. Consequently, the typical CPU cost of an actual disk access will be closer to the random-access cost than to the sequential-access cost.
- Communications I/O
- If disk I/O is actually to Network File System (NFS) remote-mounted file systems, the disk I/O is performed on the server, but the client experiences higher CPU and memory demands.
- RPCs of any kind contribute substantially to the CPU load. The proposed RPCs in the design should be minimized, batched, prototyped, and measured in advance.
- Each sequential NFS read or write of an 4 KB page takes about 600 units on the client. Each random NFS read or write of a 4 KB page takes about 1000 units on the client.
- Web browsing and Web serving implies considerable network I/O, with TCP connections opening and closing quite frequently.