* What does the "MMU" do?

MMU: Memory Management Unit

MMU is a piece of h/w that sits b/t the CPU and main memory (RAM).  The MMU
will "load" a list of virtual-to-physical mappings of pages for a running
process/task, and will translate V2P/P2V in both directions.  This is used
to maintain a "virtual memory" illusion to user processes, every process
THINKS they have access to a lot of memory, but inside the OS, fewer
physical pages are dynamically un/re/mapped to processes.  MMU also ensures
that page protections aren't violated (else you get a SIGSEGV, and core
dump).  More on virtual/physical later in the course.

MMU is a piece of hardware, NOT software.  Why? b/c it has to translate mem
addresses at CPU/RAM speeds.

One of the things that an MMU does, is mark a single "bit" for every page of
memory, when that memory address passes through the MMU.  This is done
essentially at line speeds, or "for free" (very very fast).

* Who uses the buffer cache?

What is a "buffer cache"?  Hint: an older term.

The buffer cache stores recently read files that were brought from slower
media (e.g., disks).  Whereas a page cache caches memory pages of running
processes (e.g., STACK, HEAP, TEXT pages).

Overlap: when a process reads a file, possibly using mmap, including shared
libraries, those are part of the process address space.  In that case, it'd
be a waste to store file's data in two separate caches.  Solution: some
15-20 years ago, most OSs merged their page+buffer caches into one cache.

* What is a "context switch"?

When the kernel is switching from running one task/process to another, on
the same physical CPU/core.  When a process runs on a CPU, there's a lot of
state that has to be maintained: status of all important CPU registers, like
the program counter (PC), or stack pointer (SP), and others.  So before we
can let another process run, we have to SAVE the state of registers (and
anything else) in a "task struct" (Linux), save it in main memory, and ONLY
then, we can bring another process to run on the same cpu/core.  But we'll
have to RESTORE the state of the CPU for the new process, to where it was
the last time that process ran.  Moving in/out of running a process on a
CPU, is this "switching of contexts".

Context switching (CS) should happen quickly b/c user processes aren't
running while you switch.  Often this code is written in a mix of C and
custom assembly code.

CS is not to be confused with a "mode switch", where the kernel moves
between unprivileged (running user processes with restrictions) and
privileged status (running in "kernel mode" with full access to all
resources, such as devices).

* What is a "system call"?

... compared to a non-system call, or a library function call.

Both look the same: have a name, takes 0 or more args, and returns a value
(unless it's a void fxn).

Main diff: syscalls execute in kernel space, kernel mode, with elevated
privileges.

* What does the "two hand-clock" refer to?

Context: paging algs, specifically a "page/cache reclamation" algorithm.

What is a cache?  A copy of a subset of data, placed into a "faster" storage
memory (e.g., RAM), where the source of the data comes from a bigger but
much slower media (e.g., network, hard disk).  Speed difference is often
1000x or more.

Why do we copy some data from slow to fast device?  The idea of caching is
that you ASSUME that the same data will be re-read in the near future, and
hence can be retrieved a second time from a faster storage device.

So all's we, but at some point, we'll run out of room in the cache device.
Why, b/c cache devices by definition are smaller, faster, and hence more
expensive.  So if my cache fills up and I need to bring a new item into the
cache, I have no choice but to EVICT something else from the cache?

What should I evict?  So, evict the oldest stuff in the cache.  Turns out
this heuristic works really well on average, but not perfect.  Many
algorithms have been devised and proposed over the years.

One example is the Least Recently Used (LRU) arg: LRU monitors when was an
item used recently, and then it evicts items that haven't been used
recently.

Hypothetical LRU alg: suppose I'm caching 4KB pages, and suppose I have 1000
such pages in my cache.  One possible LRU is: each time I read or write to
any byte within a page, I get a nanosecond-resolution 64-128 bit timestamp
(available in most modern CPUs) and record it with the page.  Then, when I
need to evict pages, I stop, use a sorting algorithm (best known complexity
is O(n*log_n), ala quick sort).  Then I can go from oldest timestamp and
evict till I made enough room.

This alg will work, but is highly inefficient!  Inside the OS, we are very
careful (read: obsessed) with consumption of resources.  This alg will have
consumed 4-8 bytes of space per page, that's a total of 4000-8000 bytes or
almost 1-2 whole PHYSICAL (not virtual) mem pages I'm wasting on "accounting
for timestamps".  Next, I have to call an instruction to get a timestamp,
and that alone can take many CPU cycles.  Finally, a sorting alg in the
kernel is WAY too expensive!

Worst of all, note that I said "stop" before you sort?  What do we stop?  We
stop accepting new accesses to the cache!  In effect, you'd need some sort
of a lock on the entire cache WHILE you are sorting and evicting!

Q: why not keep the cache data structure in sorted order (sorted array,
sorted tree, etc.)?  A: you'd still be paying too high a cost, amortized
each time you update a cache element, or add/remove an element: you'll need
to resort the d-s so it's in sorted order.

Solution: is don't try to be perfect ("Perfect is the enemy of good").  It's
ok to be "good enough" using an approximation algorithm.  Hence the "two
hand clock" algorithm:

1. Reset all the "used" bits in the MMU to 0.  That's usually fairly easy
   and fast to do at h/w speed in the MMU
2. Start a timer, illustrated often as starting the minute hand of a clock
   at N seconds to midnight (12 oclock).  Then wait for N seconds (or any
   other time unit you want).
[Something happens here, while you wait N seconds]
3. Come back after N seconds, and check the status of the "used" bits in the
   MMU's pages.

At step 3, you'll find that some pages' bits are now "1" while others remain
at 0.  Those set of 1, meaning they were actively in use while you were
waiting N seconds, and the MMU turned those bits on "for free".

So now, just go and look at all the pages with "0" bits, pick some, and
evict them.  Why, b/c those pages haven't been used recently, at least not
for N seconds.  This alg isn't perfect: it may evict a page that wasn't used
just over N seconds, while leaving behind a page that's much older, but
that's the approximation of this heuristic.

You can tune this LRU alg by changing the value of N, how long you wait.  If
N is too long, too many page are marked "used", and you may not have enough
pages to evict.  If you set N too small, you may find that you have plenty
of pages to evict, but you're evicting possibly pages that will be used in
the near future.

Locking (lots more during the course): with the above alg, you don't need to
lock the entire cache.  You only need to lock a single cached element (e.g.,
page) before you discard it, to ensure that no other user tries to access
that page while the kernel is trying to discard it.

Q: Is this alg running in the bg or when the cache is full, or
synchronously?  A: all of the above.  Lots more when we discuss mem mgmt.
Briefly, by default the OS will run such tasks in the bg (kernel thread, or
kthread).  But, OSs will also take stronger measures, if the previous less
strict measures didn't work: performing cleaning in the foreground,
synchronously, and even locking out some processes from being able to run, so
the kernel's job can take place.

* What does the unlink(2) system call?

"deletes a file".  It deletes other kinds of objects too, like a symlink, a
hardlink, even a block/char device.

Can it delete a directory? No: that's why we have rmdir(2).

"delete" is not quite right either.  It was called "unlink" for a reason: it
"removes one name" of a file from the namespace, but does NOT immediately
delete the file's content or its metadata (inode).  Why "one name"?  Because
files can have MULTIPLE names (e.g., "hard linked files", or aliases).

Unlink will remove one name.  If at some point you've removed ALL names of a
(hard linked) file, then the file's inode+data will have no more named
references in the f/s, and ONLY then, can the inode and data be removed from
storage (finally, deleting the file).

Unlink returns immediately, synchronously.  But if the inode+data have to be
removed, that process takes place asynchronously, often by kernel "garbage
collection" threads?

OS lesson: anything you don't have to do now, defer till later.  Lots of
asynchrony.

* What does the ln -s command do?

It creates a symlink (or softlink).  Calls the symlink(2) syscall.

ln(1) can also create HARD links, w/o the -s option.  Calls the link(2)
syscall.

* What does this command do: gcc -W main.c -o bar -lssl

gcc: the C compiler
-W: enable "some" warnings
-Wall: enable "lots" more warnings
main.c: program to compile
-o: the output binary option
bar: the name of the o/p binary (else defaults to "a.out")
-lssl: link with libssl.so as well

* documentation

Side bar: what is this "(2)" after the name of the syscall, or "(1)"?  This
points out to the section of the help/documentation, or manual/man pages in
UNIX.  A convention is XXX(N) where "XXX" is the name of the function, and
"N" is the type or section of the man pages you'll find it in.  Sections:

1: user commands
2: syscalls
3: library calls
5: formats
8: sysadmin/root commands

$ man ln
$ man stat
$ man 1 stat # get info on the /bin/stat command
$ man 2 stat # get info on the stat system call

# LocalWords:  RUNNABLE MMU SIGSEGV mem