OSTEP Ch. 13 Homework: Where Did My RAM Go?

I work through the OSTEP Chapter 13 (Address Spaces) homework on a Linux box in GitHub Codespaces: free, a little memory-hungry C program (memory-user.c), ps and pmap. Why "free" looks tiny while "available" is big, why memory only becomes real once you touch it, what happens when you ask for more RAM than the machine has, and how many pieces a "simple" address space really has. Operating Systems: Three Easy Pieces (free online): https://pages.cs.wisc.edu/~remzi/OSTEP/ This chapter (PDF): https://pages.cs.wisc.edu/~remzi/OSTE... Chapter 13 reading video:    • OSTEP Ch. 12–13: Every Address You Print I...   Chapters 0:00 Homework recap 0:47 Intro 2:32 Q1-2: free 3:03 No Linux machine? Codespaces 4:42 free vs available 5:26 Q3: memory-user.c 8:19 Q4: watch free while it runs 8:37 Asking for too much memory 9:41 Q5: pmap 10:17 pmap on memory-user 12:03 Q6-7: ps 13:16 The answers Answers in short Q1-2: "available", not "free", is the number that matches your intuition. Linux fills idle RAM with page cache (buff/cache) and hands it back on demand. Q3: malloc only hands out addresses; RAM is used once you write to the pages (demand paging), so memory-user touches every entry. Q4: "used" climbs by about the array size while it runs and drops back when it exits. 640000 MB and 64000 MB: malloc refuses. 6400 MB fits: Linux throws out page cache to make room, and the run got terminated. Q5-7: ps auxw finds a PID; pmap -x shows ~23 mappings even for a tiny program (program, heap, libc, the dynamic loader, stack, vdso...). A browser has hundreds to thousands. Q8: the big array is its own anonymous mapping near the libraries, not on the heap (glibc sends large requests to mmap). RSS smaller than the size means the loop hasn't touched every page yet. On a Mac: vm_stat / top -l 1 instead of free, vmmap PID instead of pmap. #operatingsystems #ostep #virtualmemory #linux #computerscience