Placement Policies, I/O

Tom Kelliher, CS 240

Apr. 26, 2000

Administrivia

Announcements

Distribute, collect homework.

Assignment

Read 8.4,5.

For those with fewer than 2 points in the bank: problem 8.25. Due in three days.

From Last Time

Static placement policies, thrashing.

Outline

  1. Dynamic placement policies.

  2. Introduction to I/O system design.

Coming Up

Buses, interfaces.

Placement Policies

Adaptive Allocation Policies

Attempt to adapt to process behavior.

Action on memory over-commitment?

Working Set Model

Idea:

  1. ``Locality.''

  2. Number of pages for each locality.

  3. This is the working set.

How do we determine the working set?

  1. : working set window.

  2. : working set interval.

  3. Every time units, examine last references and determine number of unique references. That number is the working set size.

  4. How do we implement this?
    1. System daemon and timer interrupt.

    2. Concatenate a few reference bits.

  5. What happens if the window straddles two localities, etc.? (Working set aliasing)

Page Fault Frequency

  1. Ultimate goal: maintain each process' page fault rate within some target region.

  2. Implementation: Track each process' fault rate
    1. If above target region: allocate more frames to process.

    2. If below target regions: de-allocate frames.

  3. Implementation?

I/O

Generally, I/O is slow, relative to CPU rates. Why? (I/O often relies upon human or mechanical processes.)

Thus, semiconductor advances don't benefit the I/O subsystem, causing it to become the bottleneck.

An Example:

  1. Suppose we have a benchmark that runs in 100 s, where 90 s. is CPU time and the rest I/O time. If CPU time improves by 50% per year over the next five years, but I/O time doesn't improve, how much faster will our program run at the end of five years?

  2. Improved CPU time at the end of one year: .

  3. Improved CPU time at the end of five years:

  4. Run time at the end of five years: 21.85 s.

    CPU speedup: .

    Program speedup: .

  5. Originally, I/O time was 10% of the total time.

    Now, it's 46% of the total.

Some I/O System Considerations

  1. I/O can be:

  2. Latency: Delay between request and first data received.

  3. Bandwidth: The rate at which data can be transferred.

Example 1:

  1. You're here in Maryland, on a T1, accessing a web page on a web server in California.

  2. The files composing the web page are in RAM cache. In total, you access 1MB of data in downloading the web page.

  3. What delay dominates, latency (minimally 32 ms) or bandwidth?

  4. Repeat, assuming you have a gigabit connection.

  5. Can we overcome latency?
    1. Hard to get around the speed of light.

    2. Caching data locally. Problems such as updates, validity. Does this solve the problem? Is the problem solvable?

Example 2:

  1. You have a system with a 1 GHz CPU and a gigabit ethernet card.

  2. The ethernet card interrupts each time it receives 16 bytes.

  3. The ethernet interrupt handler requires executing 200 instructions. (This is probably optimistic.)

  4. Do you get any work done?
    1. Bytes received per second: 1E8.

    2. Ethernet interrupts per second: 6.25E6.

    3. Cpu cycles spent handling interrupts: 1.25E9.

    4. Time spend handling one second of ethernet data: 1.25 s.

Software System Examples

  1. Supercomputing: Weather forecasting. Supercomputing applications tend to process large volumes of data, putting a premium on I/O bandwidth.

  2. ``Back Office'' computing: Online transaction processing. Client/Server. This involves database operations: queries, adds, deletes, edits. Requests from large geographical areas are aggregated at one database server. Very large transaction volumes (airline ticketing systems). For this reason, databases often kept in RAM (several GB of RAM).

  3. e-Commerce computing: Client/Server. Client: web browser. Server: web server (Apache, etc.) feeding dynamic HTML and data from a SQL (MySQL, Oracle, etc.) database server. CGI used to interface the two.



Thomas P. Kelliher
Wed Apr 26 08:51:24 EDT 2000
Tom Kelliher