Skip to main content Link Menu Expand (external link) Document Search Copy Copied

CS 326 Lecture/Lab Spring 2025 Meeting Summary

Date: May 06, 2025
Time: 02:51 PM Pacific Time (US and Canada)
Meeting ID: 813 3845 7711

Overview

The lecture covered various aspects of operating systems, including virtual memory management, process forking, and file systems. The instructor addressed student questions, provided updates on course materials and exams, and discussed the challenges of teaching operating systems concepts. Participants were encouraged to explore topics beyond the course material and to deeply understand the system code.

Quick Recap

  • Operating Systems Fundamentals:
    The lecture covered key concepts such as:
    • Virtual Memory Management
    • Process Forking
    • File Systems

  • Instructional Challenges:
    The instructor discussed the difficulties in teaching operating systems, emphasizing the importance of thorough understanding over surface breadth.

  • Exams and Project Updates:
    Updates were given regarding upcoming exam formats and project solution releases.

Project Concepts and Grading Process

  • Project Discussions:
    • Detailed explanations of project concepts (e.g., virtual memory tables).
    • Addressed questions posted on campus wire.
  • Grading Process:
    • Provided details for Project 4 and clarified how grading will be managed.
    • Solutions for Project 2 and Project 3 practice exam problems will be released.
    • Project 4 exam problem solutions will be available.
  • Final Exam Information:
    • The final exam will be cumulative:
      • 75% covering material from midterm onward.
      • 25% from the first half of the semester.
    • Students are allowed two pages of notes during the final exam.
  • Additional Topics:
    Future lectures may include operating system topics not yet covered in the course.

Unmapping and Deallocating Pages in Virtual Memory

The lecture explained the process of unmapping and deallocating pages within the virtual memory system. The instructor detailed how the system:

  1. Walks through the page table starting at address 0, incrementing by the page size.
  2. Checks for valid page table entries.
  3. Depending on the do_free parameter:
    • Removes the mapping.
    • Optionally deallocates the physical memory, returning it to the kernel’s free list.

Memory Unmapping Process Diagram

flowchart TD
    A[Start at address 0]
    B[Increment by page size]
    C[Check if page table entry PTE is valid]
    D{Is page mapped?}
    E[If do_free is set]
    F[Free physical memory]
    G[Remove mapping from page table]
    H[Continue loop]

    A --> B
    B --> C
    C --> D
    D -- Yes --> E
    D -- No --> H
    E --> F
    F --> G
    G --> H
    H --> B

uvmunmap() Function Memory Management

The instructor highlighted an issue found in the memory unmapping functionality within the UV unmapped function implementation:

  • Original Issue:
    The loop intended to handle shared memory regions did not reach the shared memory address.

  • Correction Approach:
    A special case was added after the loop to check:
    • If the shared memory region is mapped.
    • Unmap it if necessary.
  • Discussion Points:
    • Scenarios such as deallocating heap space via negative S break calls.
    • The importance of understanding the nuances of memory management in operating systems.

Uvm_copy in the Fork System Call

The lecture discussed the uvm_copy function in the context of the fork system call. Key points include:

  • Purpose of uvm_copy:
    • Creates a complete copy of the parent’s address space for the child process.
    • Allocates new pages for the child and copies content page-by-page.
  • Process Details:
    • The child process receives its own page table.
    • The child’s mappings are initially identical to those of the parent.
    • Additional mappings may be added if the child allocates more heap space.
    • In cases where the child calls exec, the current page table is discarded and replaced.

xv6-riscv C Code Example: uvm_copy

// Copy parent's address space to the child's, used during fork.
int uvm_copy(pagetable_t dst, pagetable_t src, uint64 size) {
    uint64 a;
    for(a = 0; a < size; a += PGSIZE) {
        pte_t *pte = walk(src, a, 0);
        if(pte == 0 || !(*pte & PTE_V))
            continue;

        char *pa = PTE2PA(*pte);
        char *mem = kalloc();
        if(mem == 0)
            return -1;
        memmove(mem, pa, PGSIZE);
        if(mappages(dst, a, PGSIZE, (uint64)mem, PTE_R | PTE_W | PTE_X) != 0) {
            kfree(mem);
            return -1;
        }
    }
    return 0;
}

Fork Process Flow Diagram

flowchart TD
    A[Parent Process]
    B[Call fork]
    C[Child Process with copied address space]
    D[New page table created for child]
    E[Exec replaces child's page table if needed]

    A --> B
    B --> C
    C --> D
    D --> E

Forking System Calls and Teaching Challenges

  • Fork System Call Behavior:
    • On calling fork, the child process initially replicates the parent’s memory content.
    • Over time, the parent and child may diverge as they perform separate operations.
  • Analogy Provided:
    • The instructor compared forking to cloning a person—initially identical, then diverging.
  • Real-World Example:
    • Early web servers used forking to improve concurrency.
  • Teaching Observations:
    • Many students struggle with pointers and memory management.
    • The instructor stresses depth over breadth in teaching critical operating system concepts.

File System Structure and Evolution

The lecture provided an overview of file systems, focusing on the following areas:

  • Block-Based Storage:
    Modern file systems manage data in blocks, conceptually similar to virtual memory management.

  • Inodes:
    • Act as the mapping structure for file data.
    • Contain direct pointers for small files.
    • Use indirect pointers for larger files to efficiently manage storage.
  • Evolution of Reliability:
    • Development of journaled and log-structured file systems has greatly reduced disk corruption issues during unexpected shutdowns.

File System Structure Diagram

flowchart LR
    A[File System]
    B[Inode]
    C[Direct Block Pointers]
    D[Indirect Block Pointers]

    A --> B
    B --> C
    B --> D

File Systems and Disk Corruption

  • Handling Disk Corruption:
    • File systems now often employ journaling or logging systems.
    • A sequential log of changes is maintained on a reserved disk area.
  • Failure Scenarios:
    • If the computer shuts down before the log is complete, pending changes are discarded.
    • If shutdown occurs during changes, the log can be replayed on restart to maintain consistency.
  • Additional Note:
    • The instructor remarked on the relative lack of networking features in the Xd6 system and encouraged further exploration in adding new functionalities.

Conclusion

The lecture covered critical operating system concepts from virtual memory management to file system structures. The instructor emphasized hands-on understanding of code (including examples from xv6-riscv) and encouraged students to ask questions and further investigate additional topics beyond the formal curriculum.