https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2021F_Lecture_22 2026-04-06T04:46:33Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2021F_Lecture_22&diff=23577&oldid=prev 2021-12-07T19:10:26Z

<p>Created page with &quot;==Video== Video from the lecture given on December 7, 2021 is now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2021f/lectures/comp3000-2021f-lec22-20211207.m4v...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on December 7, 2021 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2021f/lectures/comp3000-2021f-lec22-20211207.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2021f/lectures/comp3000-2021f-lec22-20211207.cc.vtt auto-generated captions]<br /> Video is also available through Brightspace (Resources-&gt;Class zoom meetings-&gt;Cloud Recordings tab)<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 22<br /> ----------<br /> <br /> When you make a system call, what is happening?<br /> - process executes &quot;syscall&quot; instruction<br /> - causes CPU to go into supervisor mode<br /> - jumps to system call entry point into kernel<br /> - syscall entry looks at CPU registers, decides<br /> what system call was requested<br /> - note this is all in assembly generally<br /> - calls appropriate system call, it does its thing<br /> - this is in C, but with weird declarations<br /> (SYSCALL_DEFINE0, SYSCALL_DEFINE1, etc)<br /> - in the kernel, the process that made the system call<br /> is represented by current (type struct task_struct)<br /> - when system call code returns, kernel<br /> switches back to user mode via the scheduler<br /> - decides what process to run next<br /> <br /> <br /> CPU registers<br /> - think of them as hard-coded variables<br /> - limited number of them<br /> - the storage you can actually do computation on<br /> - basic flow (load/store architecture)<br /> - load values into registers from memory<br /> - do operations on registers, with results in<br /> registers<br /> - save registers to memory<br /> - when you make a system call registers hold<br /> system call parameters<br /> - this can also happen when you call a C function,<br /> but it depends on the compiler<br /> - system call ABI (application binary interface)<br /> is explicitly defined by the Linux kernel<br /> <br /> Remember with the file API there is always file state<br /> for open files<br /> - our position in the file<br /> <br /> The implicit in userspace must be explicit in kernelspace<br /> - we have to represent our position in the file<br /> <br /> mutex<br /> - ensure exclusive access to a resource<br /> - essentially, a lock<br /> - needed when concurrent access to something<br /> could mess it up (i.e., messing up a data structure<br /> or variable)<br /> - (a mutex is a semaphore that can have a value of 0 or 1)<br /> - (for mutual exclusion, hence the name)<br /> <br /> condition variable<br /> - wait on an event to happen<br /> - so one party waits while another tells it<br /> to stop waiting<br /> <br /> In this situation, the condition variable is the resource<br /> being protected by the mutex<br /> <br /> A virtual address can be divided into a virtual page number<br /> and an offset within a page<br /> - so to go to physical memory, we map the page number<br /> to a frame<br /> - we just copy the offset - it isn&#039;t changed<br /> (it is just an index into a 4k array, which is the page)<br /> <br /> slab allocation in the kernel<br /> - used for kernel data structures<br /> - on top of virtual memory<br /> <br /> slab allocation is just a fancy malloc<br /> - that understands patterns in the kinds of data being allocated<br /> <br /> The idea is that we don&#039;t want to waste time allocating<br /> data structures<br /> - so reuse them when we can<br /> - initialize in the background, not on critical paths<br /> <br /> remember dynamic memory allocation is expensive<br /> - often a huge bottleneck in any complex program<br /> <br /> To solve this, use custom memory allocators<br /> - the slab allocator is just the kernel&#039;s<br /> <br /> garbage collection is a fancy memory management strategy<br /> used for languages with heavy uses of dynamic memory allocation<br /> - basically, used when you don&#039;t explicitly free<br /> allocated storage<br /> <br /> <br /> Why do we use pages?<br /> - because allocating/deallocating fixed-sized chunks<br /> of memory is about as efficient as we can get<br /> &lt;/pre&gt;</div>

Soma