DOC PREVIEW
Stanford CS 144 - Study Notes

This preview shows page 1-2-15-16-31-32 out of 32 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Review: Hardware user/kernel boundarylibkerneluser lib libapplic. applic. applic.syscallsocketsNICsyscalldiskFScontext switchdevice interruptsTCP retransmits, ...diskpg faultVM• Processor can be in one of two modes- user mode – application software & libraries- kernel (supervisor/privileged) mode – for the OS kernel• Privileged instructions only available in kernel modeExecution contexts• User – executing unprivileged application code• Top half of kernel (a.k.a. “bottom half” in Linux)- Kernel code acting on behalf of current user-level process- System call, page fault handler, kernel-only process, etc.- This is the only kernel context where you can sleep(e.g., if you need to wait for more memory, a buffer, etc.)• Software interrupt- Code not acting on behalf of current process- TCP/IP protocol processing• Device interrupt- External hardware causes CPU to jump to OS entry point- Network interface cards generate these, disks too, . . .• Timer interrupt (hardclock)• Context switch code – change top half threadTransitions between contexts• User → top half: syscall, page fault- E.g., Read or write to a socket• User/top half → device/timer interrupt: hardware- E.g., network transmission complete or a packet has arrived• Top half → user: syscall return- Note syscall return can also go to context switch (e.g., if packethas arrived and made sleeping process runnable)• Top half → context switch: sleep- E.g., User called read on a TCP socket, but no data yet• Context switch → user/top half: return (to new ctx)Process contextlibapplic.syscallsocketsNIClibapplic.syscalldiskFSlibapplic.context switchdevice interruptsTCP retransmits, ...diskpg faultVMP1P2P3• Kernel gives each program its own context• Isolates processes from each other- So one buggy process cannot crash othersVirtual memory• Fault isolation between processes requires memoryisolation• Want each process to have its own view of memory- Otherwise, pain to allocate large contiguous structures- Processes can consume more than available memory- Dormant processes (wating for event) still have core images• Solution: Virtual Memory- Give each program its own address space—I.e., Address0x8000 goes to different physical memory in P1and P2- CPU must be in kernel mode to manipulate mappings- Isolation between processes is naturalPaging• Divide memory up into small pages• Map virtual pages to physical pages- Each process has separate mapping• Allow OS to gain control on certain operations- Read-only pages trap to OS on write- Invalid pages trap to OS on write- OS can change mapping and resume application• Other features sometimes found:- Hardware can set “dirty” bit- Control caching of pageExample: Paging on x86• Page size is 4 KB (in most generally used mode)• Page table: 1024 32-bit translations for 4 Megs ofVirtual mem• Page directory: 1024 pointers to page tables• %cr3—page table base register• %cr0—bits enable protection and paging• INVLPG – tell hardware page table modifiedPage DirectoryDirectory EntryCR3 (PDBR)Page TablePage−Table Entry4−KByte PagePhysical Address32*101210200irectorye f s31 21 111222Linear AddressDTabl O f et*32 bits aligned onto a 4−KByte boundary1024 PDE × 1024 PTE = 220Pages31Available for system programmer’s useGlobal PagePage Table Attribute IndexDirty12 1198765 4 3210PCADAccessedCache DisabledWrite−ThroughUser/SupervisorRead/WritePresentDPPWTU/SR/WAvailPage Base AddressPage−Table En ry (4−KB yte Page)PATGtExample: MIPS• Hardware has 64-entry TLB- References to addresses not in TLB trap to kernel• Each TLB entry has the following fields:Virtual page, Pid, Page frame, NC, D, V, Global• Kernel itself unpaged- All of physical memory contiguously mapped in high VM- Kernel uses these pseudo-physical addresses• User TLB fault hander very efficient- Two hardware registers reserved for it- utlb miss handler can itself fault—allow paged page tablesMemory and I/O busesI/O bus1880Mbps 1056MbpsCrossbarMemoryCPU• CPU accesses physical memory over a bus• Devices access memory over I/O bus with DMA• Devices can appear to be a region of memoryRealistic Pentium architectureI/OAPICAdvancedProgramableInterruptControllerbusCPUBridgeMainmemoryNorthSouthBridgeCPUUSBbusAGPfront-sidebusPCIbusPCIIRQsbusISAWhat is memory• SRAM – Static RAM- Like two NOT gates circularly wired input-to-output- 4–6 transistors per bit, actively holds its value- Very fast, used to cache slower memory• DRAM – Dynamic RAM- A capacitor + gate, holds charge to indicate bit value- 1 transistor per bit – extremely dense storage- Charge leaks—need slow comparator to decide if bit 1 or 0- Must re-write charge after reading, or periodically refresh• VRAM – “Video RAM”- Dual ported, can write while someone else readsWhat an is I/O bus? E.g., PCICommunicating with a device• Memory-mapped device registers- Certain physical addresses correspond to device registers- Load/store gets status/sends instructions – not real memory• Device memory – device may have memory OS canwrite to directly on other side of I/O bus• Special I/O instructions- Some CPUs (e.g., x86) have special I/O instructions- Like load & store, but asserts special I/O pin on CPU- OS can allow user-mode access to I/O ports with finergranularity than page• DMA – place instructions to card in main memory- Typically then need to “poke” card by writing to register- Overlaps unrelated computation with moving data over(typically slower than memory) I/O busDMA buffersBufferdescriptorlistMemory buffers1001400150015001500…• Include list of buffer locations in main memory• Card reads list then accesses buffers (w. DMA)- Allows for scatter/gather I/OAnatomy of a Network Interface CardHost I/O busNetwork LinkAdaptorBusInterfaceLinkInterface• Link interface talks to wire/fiber/antenna- Typically does framing, link-layer CRC• FIFOs on card provide small amount of buffering• Bus interface logic uses DMA to move packets toand from buffers in main memoryContext switches are expensive• Modern CPUs very complex- Deep pipelining to maximize use of functional units- Dynamically scheduled, speculative & out-of-order execution• Most context switches flush the pipeline- E.g., after memory fault, can’t execute further instructions• Reenabling hardware interrupts expensive• Kernel must set up its execution context- Cannot trust user registers,


View Full Document

Stanford CS 144 - Study Notes

Documents in this Course
IP Review

IP Review

22 pages

Load more
Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?