Lazy Allocation, Demand Paging, And Overcommit#
Lazy Allocation, And Overcommit#
Mappings are unpopulated, initially
Not backed by physical memory
⟶ MMU knows nothing
⟶ Error condition
Memory will be allocated at first access
⟶ overcommit: if all processes allocated memory for all of their mappings, the system would run out of memory
(generally, they don’t)
libreoffice extension dead:
drawings/libreoffice/lazy-alloc-unpopulated.odg
Memory Access, And Allocation#
On first access, MMU knows nothing (no TLB entry)
⟶ “TLB miss”
Page table has nothing too
⟶ Process is suspended
Memory allocation starts
Might require disk IO ⟶ could take a while
⟶ No-go if one has realtime requirements
libreoffice extension dead:
drawings/libreoffice/lazy-alloc-mmu-trap.odg
Finish: Setup Mapping, Kick Process Loose#
Finally, when allocation has taken place, page tables and TLB are updated
⟶ Process is runnable again
⟶ Subject to scheduling
libreoffice extension dead:
drawings/libreoffice/lazy-alloc-allocated.odg
Further Notes: TLB Misses, Memory Performance#
TLB misses not only occur when a mapping is unpopulated
TLB thrashing
TLB is of limited size ⟶ cannot contain all possible address mappings of a process
⟶ Needs occasional updates from OS’s page tables
Programmer’s responsibility (see Optimizations: Memory Optimizations)
Paging/swapping
The OS might have paged out memory to swap (running low on total memory?)
Technically, mapping is not unpopulated
Effect is even worse: guaranteed disk IO
Further Notes: Realtime#
Allocation may suspend a process in critical situations
⟶ Lazy allocation is not generally wanted in realtime situations
Allocations must be done up-front
Not all allocations are explicit
Program itself is loaded on-demand ⟶ bad luck if a new code branch is taken at the wrong time
Stack memory is dynamically allocated, on-demand
Global variables are lazy-loaded too
…