https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_21 2026-06-02T21:08:13Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Lecture_21&diff=22622&oldid=prev 2020-03-27T20:33:19Z

<p>Created page with &quot;==Video== Video from the lecture given on March 27, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec21-20200327.m4v is now available]. ==...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on March 27, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec21-20200327.m4v is now available].<br /> <br /> ==Resources==<br /> <br /> * [https://www.acm.org/hennessy-patterson-turing-lecture Turing Award talk by John Hennessy and David Patterson]<br /> * [https://en.wikipedia.org/wiki/Memory_hierarchy Wikipedia page on Memory Hierarchy]<br /> * [https://en.wikipedia.org/wiki/CPU_cache Wikipedia page on CPU caches]<br /> * [https://en.wikichip.org/wiki/amd/microarchitectures/zen Wikichip&#039;s page on AMD&#039;s Zen microarchitecture]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 21<br /> ----------<br /> - tutorial 8<br /> - tutorial 9<br /> <br /> Standard address space ordering<br /> <br /> command line args, env vars<br /> stack (grows down)<br /> <br /> heap (grows up)<br /> globals<br /> code<br /> <br /> <br /> Virtual memory systems rely on page replacement algorithms<br /> - decide when to kick out a page in order to make room for another in RAM<br /> - we use bits in the page table entries to decide what to do<br /> - valid bit: is this a valid PTE?<br /> - accessed bit: recently accessed (approximation of a timestamp)<br /> - dirty bit: has it been changed (i.e., do we have to save it before<br /> evicting it?)<br /> - dirty pages have to be &quot;cleaned&quot; (i.e., saved to disk) before they can be<br /> freed<br /> - we don&#039;t want to kick out recently accessed pages as they are likely<br /> to be used in the future<br /> - we&#039;d just have to load it back somewhere else, wasting time<br /> - when a program accesses parts of its virtual address space, the kernel<br /> has to make sure that memory is valid<br /> - if it is code, the code has to be loaded from disk<br /> - if data, have to make sure data page is allocated<br /> - the kernel can try to predict what a program is going to do<br /> - only makes sense in limited cases (e.g., load chunks of<br /> program binary from disk when program is first execve&#039;d)<br /> - ideally, kernel would know exactly what each process would want to do next<br /> - would make sure resources were available just in time<br /> - of course, we can&#039;t do this in practice<br /> <br /> - note that block size on disk for current filesystems<br /> nowadays equals page size (both are 4k)<br /> - not essential but useful at times<br /> - we talk about blocks on disk, not pages (but that&#039;s just terminology)<br /> <br /> <br /> <br /> <br /> The memory hierarchy (fastest storage-&gt;slowest, smallest-&gt;biggest)<br /> <br /> registers &lt;--- managed by the compiler<br /> TLB &lt;--- managed by hardware, partially by OS<br /> L1 cache &lt;--- (Per core)<br /> L2 cache &lt;--- managed by CPU itself, no software involvement <br /> L3 cache &lt;--- (Per CPU (chip))<br /> <br /> DRAM &lt;--- managed by OS<br /> ---------------- below is persistent, above, volatile, managed by software<br /> ssd <br /> hard disks<br /> tapes<br /> <br /> <br /> L1, L2, and L3 are all caches of main memory (DRAM), are SRAM<br /> - vary in speed (latency/bandwidth in being transferred to registers)<br /> - vary in size (smaller vs larger)<br /> <br /> If you want to learn about architecture in more detail, read<br /> Hennessey and Patterson, &quot;Computer Architecture: A Quantitative Approach&quot;<br /> - great book, very readable<br /> <br /> <br /> Remember how we discussed concurrency was hard, required hardware support?<br /> - think about the work required to make sure copies in L1, L2, L3, registers,<br /> and DRAM are all in sync<br /> - can have 3, 4, or 5 copies of one variable, that logically should<br /> always be the same but in practice can get out of sync<br /> <br /> <br /> <br /> you don&#039;t have to make sure DRAM is in sync with the caches, that happens<br /> automatically<br /> - it just isn&#039;t perfect when you access DRAM in parallel from muliple cores,<br /> you can see (slightly) stale data<br /> <br /> The real secret of modern systems is that while we program mostly sequentially,<br /> hardware runs things in parallel and *pretends* it all happened sequentially<br /> &lt;/pre&gt;</div>

Soma