Lazy Allocation, Demand Paging, And Overcommit

Lazy Allocation, And Overcommit

Mappings are unpopulated, initially No memory exists ⟶ no mapping exists in MMU 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 has no mapping (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, allocation has taken place (allocated memory is zero-filled, btw) Kernel page tables modified, TLB entry in place ⟶ 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?

• Lazy allocation is not generally wanted in realtime situations

• Allocations must be done up-front

  • Program itself (code and data) is loaded on-demand ⟶ bad luck if a new code branch is taken at the wrong time

  • Stack memory is dynamically allocated

  • …