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)

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

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

Further Notes: TLB Misses, Memory Performance

See also

• Optimizations: Memory Optimizations

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

See also

• TODO: And 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

  • Global are lazy-loaded too

  • …