Operating Systems 2021F Lecture 22

Video

Video from the lecture given on December 7, 2021 is now available:

• video
• auto-generated captions

Video is also available through Brightspace (Resources->Class zoom meetings->Cloud Recordings tab)

Notes

Lecture 22
----------

When you make a system call, what is happening?
 - process executes "syscall" instruction
 - causes CPU to go into supervisor mode
 - jumps to system call entry point into kernel
 - syscall entry looks at CPU registers, decides
   what system call was requested
     - note this is all in assembly generally
 - calls appropriate system call, it does its thing
     - this is in C, but with weird declarations
       (SYSCALL_DEFINE0, SYSCALL_DEFINE1, etc)
     - in the kernel, the process that made the system call
       is represented by current (type struct task_struct)
 - when system call code returns, kernel
   switches back to user mode via the scheduler
     - decides what process to run next


CPU registers
 - think of them as hard-coded variables
    - limited number of them
    - the storage you can actually do computation on
    - basic flow (load/store architecture)
      - load values into registers from memory
      - do operations on registers, with results in
        registers
      - save registers to memory
 - when you make a system call registers hold
   system call parameters
     - this can also happen when you call a C function,
       but it depends on the compiler
     - system call ABI (application binary interface)
       is explicitly defined by the Linux kernel

Remember with the file API there is always file state
for open files
 - our position in the file

The implicit in userspace must be explicit in kernelspace
 - we have to represent our position in the file

mutex
 - ensure exclusive access to a resource
 - essentially, a lock
 - needed when concurrent access to something
   could mess it up (i.e., messing up a data structure
   or variable)
 - (a mutex is a semaphore that can have a value of 0 or 1)
 - (for mutual exclusion, hence the name)
 
condition variable
 - wait on an event to happen
   - so one party waits while another tells it
     to stop waiting

In this situation, the condition variable is the resource
being protected by the mutex

A virtual address can be divided into a virtual page number
 and an offset within a page
  - so to go to physical memory, we map the page number
    to a frame
  - we just copy the offset - it isn't changed
    (it is just an index into a 4k array, which is the page)

slab allocation in the kernel
 - used for kernel data structures
 - on top of virtual memory

slab allocation is just a fancy malloc
 - that understands patterns in the kinds of data being allocated

The idea is that we don't want to waste time allocating
data structures
 - so reuse them when we can
 - initialize in the background, not on critical paths

remember dynamic memory allocation is expensive
 - often a huge bottleneck in any complex program

To solve this, use custom memory allocators
 - the slab allocator is just the kernel's

garbage collection is a fancy memory management strategy
used for languages with heavy uses of dynamic memory allocation
 - basically, used when you don't explicitly free
   allocated storage


Why do we use pages?
 - because allocating/deallocating fixed-sized chunks
   of memory is about as efficient as we can get