Backing Store

The issue is where on disk do we put pages.

• For program text, which is presumably read only, a good choice is the file itself.
• What if we decide to keep the data and stack each contiguous on the backing store. Data and stack grow so must be prepared to grow the space on disk and leads to the same issues and problems as we saw with MVT.
• If those issues/problems are painful, we can scatter the pages on the disk.
  • That is we employ paging!
  • This is NOT demand paging.
  • Need a table to say where the backing space for each page is located.
    • This corresponds to the page table used to tell where in real memory a page is located.
    • The format of the ``memory page table'' is determined by the hardware since the hardware modifies/accesses it.
    • The format of the ``disk page table'' is decided by the OS designers and is machine independent.
    • If the format of the memory page table was flexible, then we might well keep the disk information in it as well.

Paging Daemons

Done earlier

Page Fault Handling

1. The hardware detects the fault and traps to the kernel (switches to supervisor mode and saves state).
   
   
2. Some assembly language code save more state, establishes the C-language (or another programming language) environment, and ``calls'' the OS.
   
   
3. The OS determines that a page fault occurred and which page was referenced.
   
   
4. If the virtual address is invalid, process A is killed. If the virtual address is valid, the OS must find a free frame. If there is no free frames, the OS selects a victim frame. Call the process owning the victim frame, process B. (If the page replacement algorithm is local process B is process A.)
   
   
5. If the victim frame is dirty, the OS schedules an I/O write to copy the frame to disk. Thus, if the victim frame is dirty, process B is blocked (it might already be blocked for some other reason). Process A is also blocked since it needs to wait for this frame to be free. The process scheduler is invoked to perform a context switch.
   
   
   • Tanenbaum ``forgot'' some here.
   • The process selected by the scheduler (say process C) runs.
   • Perhaps C is preempted for D or perhaps C blocks and D runs and then perhaps D is blocked and E runs, etc.
   • When the I/O to write the victim frame completes, a Disk interrupt occurs. Assume processes C is running at the time.
   • Hardware trap / assembly code / OS determines I/O done.
   • Processes A is moved from blocked to ready as is process B (unless B is also blocked for some other reason).
   • The scheduler picks a process to run, maybe A, maybe B, maybe C, maybe another processes.
   • At some point the scheduler does pick process A to run. Recall that at this point A is still executing OS code.
   
   
6. Now the O/S has a clean frame (this may be much later in wall clock time if a victim frame had to be written). The O/S schedules an I/O to read the desired page into this clean frame. Process A is blocked (perhaps for the second time) and hence the process scheduler is invoked to perform a context switch.
   
   
7. A Disk interrupt occurs when the I/O completes (trap / asm / OS determines I/O done). The PTE is updated.
   
   
8. The O/S may need to fix up process A (e.g. reset the program counter to re-execute the instruction that caused the page fault).
   
   
9. Process A is placed on the ready list and eventually is chosen by the scheduler to run. Recall that process A is executing O/S code.
   
   
10. The OS returns to the first assembly language routine.
    
    
11. The assembly language routine restores registers, etc. and ``returns'' to user mode.

Process A is unaware that all this happened.

3.7: Segmentation

Up to now, the virtual address space has been contiguous.

• Among other issues this makes memory management difficult when there are more that two dynamically growing regions.
• With two regions you start them on opposite sides of the virtual space as we did before.
• Better is to have many virtual address spaces each starting at zero.
• This split up is user visible.
• Without segmentation (equivalently said with just one segment) all procedures are packed together so if one changes in size all the virtual addresses following are changed and the program must be re-linked.
• Eases flexible protection and sharing (share a segment). For example, can have a shared library.

Homework: 29.

** Two Segments

Late PDP-10s and TOPS-10

• One shared text segment, that can also contain shared (normally read only) data.
• One (private) writable data segment.
• Permission bits on each segment.
• Which kind of segment is better to evict?
  • Swap out shared segment hurts many tasks.
  • The shared segment is read only (probably) so no writeback is needed.
• ``One segment'' is OS/MVT done above.

** Three Segments

Traditional Unix shown at right.

1. Shared text marked execute only.
2. Data segment (global and static variables).
3. Stack segment (automatic variables).

** Four Segments

Just kidding.

** General (not necessarily demand) Segmentation

• Permits fine grained sharing and protection.
• Visible division of program.
• Variable size segments.
• Address = (seg#, offset).
• Does not mandate how stored in memory.
  • One possibility is that the entire program must be in memory in order to run it. Use whole process swapping. Very early versions of Unix did this.
  • Can also implement demand segmentation.
  • Can combine with demand paging (done below).
• Requires a segment table with a base and limit value for each segment. Similar to a page table.
• Entries are called STEs, Segment Table Entries.
• (seg#, offset) --> if (offset<limit) base+offset else error.
• Segmentation exhibits external fragmentation, just as whole program swapping. Since segments are smaller than programs (several segments make up one program), the external fragmentation is not as bad.

** Demand Segmentation

Same idea as demand paging applied to segments.

• If a segment is loaded, base and limit are stored in the STE and the valid bit is set in the PTE.
• The PTE is accessed for each memory reference (not really, TLB).
• If the segment is not loaded, the valid bit is unset. The base and limit as well as the disk address of the segment is stored in the an OS table.
• A reference to a non-loaded segment generate a segment fault (analogous to page fault).
• To load a segment, we must solve both the placement question and the replacement question (for demand paging, there is no placement question).
• I believe demand segmentation was once implemented but am not sure. It is not used in modern systems.

The following table mostly from Tanenbaum compares demand paging with demand segmentation.

Consideration	Demand Paging	Demand Segmentation
Programmer aware	No	Yes
How many addr spaces	1	Many
VA size > PA size	Yes	Yes
Protect individual procedures separately	No	Yes
Accommodate elements with changing sizes	No	Yes
Ease user sharing	No	Yes
Why invented	let the VA size exceed the PA size	Sharing, Protection, independent addr spaces
Internal fragmentation	Yes	No, in principle
External fragmentation	No	Yes
Placement question	No	Yes
Replacement question	Yes	Yes

** 3.7.2: Segmentation with paging

Combines both segmentation and paging to get advantages of both at a cost in complexity. This is very common now.

• A virtual address becomes a triple: (seg#, page#, offset).
• Each segment table entry (STE) points to the page table for that segment. Compare this with a multilevel page table.
• The size of each segment is a multiple of the page size (since the segment consists of pages). Perhaps not. Can keep the exact size in the STE (limit value) and shoot the process if it referenced beyond the limit. In this case the last page of each segment is partially valid.

• The page# field in the address gives the entry in the chosen page table and the offset gives the offset in the page.
• From the limit field, one can easily compute the size of the segment in pages (which equals the size of the corresponding page table in PTEs). Implementations may require the size of a segment to be a multiple of the page size in which case the STE would store the number of pages in the segment.
• A straightforward implementation of segmentation with paging would requires 3 memory references (STE, PTE, referenced word) so a TLB is crucial.
• Some books carelessly say that segments are of fixed size. This is wrong. They are of variable size with a fixed maximum and possible with the requirement that the size of a segment is a multiple of the page size.
• The first example of segmentation with paging was Multics.
• Keep protection and sharing information on segments. This works well for a number of reasons.
  1. A segment is variable size.
  2. Segments and their boundaries are user (i.e., linker) visible.
  3. Segments are shared by sharing their page tables. This eliminates the problem mentioned above with shared pages.
• Do replacement on pages so there is no placement question and no external fragmentation.
• Do fetch-on-demand with pages (i.e., do demand paging).
• In general, segmentation with demand paging works well and is widely used. The only problems are the complexity and the resulting 3 memory references for each user memory reference. The complexity is real, but can be managed. The three memory references would be fatal were it not for TLBs, which considerably ameliorate the problem. TLBs have high hit rates and for a TLB hit there is essentially no penalty.

Homework: 30.

Some last words on memory management.

• Segmentation / Paging / Demand Loading (fetch-on-demand)
  • Each is a yes or no alternative.
  • Gives 8 possibilities.
• Placement and Replacement.
• Internal and External Fragmentation.
• Page Size and locality of reference.
• Multiprogramming level and medium term scheduling.

Chapter 4: File Systems

Requirements

1. Size: Store very large amounts of data.
2. Persistence: Data survives the creating process.
3. Access: Multiple processes can access the data concurrently.

Solution: Store data in files that together form a file system.

4.1: Files

4.1.1: File Naming

Very important. A major function of the file system.

• Does each file have a unique name?
  Answer: Often no. We will discuss this below when we study links.
  
  
• Extensions, e.g. the ``html'' in ``class-notes.html''.
  
  
  1. Conventions just for humans: letter.teq (my convention).
     
     
  2. Conventions giving default behavior for some programs.
     • The emacs editor thinks .html files should be edited in html mode but
       can edit them in any mode and can edit any file in html mode.
     • Netscape thinks .html means an html file, but
       <html> ... </html> works as well
     • Gzip thinks .gz means a compressed file but accepts a --suffix flag
     
     
  3. Required extensions for programs
     • The gnu C compiler (and probably others) requires C programs be named *.c and assembler programs be named *.s
     
     
  4. Required extensions by operating systems
     • MS-DOS treats .com files specially
     • Windows 95 requires (as far as I can tell) shortcuts to end in .lnk.
  
  
• Case sensitive?
  Unix: yes. Windows: no.

4.1.2: File structure

A file is a

1. Byte stream
   • Unix, dos, windows (I think).
   • Maximum flexibility.
   • Minimum structure.
   
   
2. (fixed size) Record stream: Out of date
   • 80-character records for card images.
   • 133-character records for line printer files. Column 1 was for control (e.g., new page) Remaining 132 characters were printed.
   
   
3. Varied and complicated beast.
   • Indexed sequential.
   • B-trees.
   • Supports rapidly finding a record with a specific key.
   • Supports retrieving (varying size) records in key order.
   • Treated in depth in database courses.