Consolidating representations of the physical memory
summary
Argues for a single coarse-grain representation of physical memory that matches firmware maps and survives boot and kexec, proposes reusing or extending memblock or the resource tree instead of creating yet another structure, calls out a painful e820→memblock gap on x86 that causes cyclic dependencies and bugs, notes memblock already drives hotplug on PowerPC and arm64, reports ongoing coordination with firmware efforts (Universal Firmware / FDT) and asks for volunteers to fix integration.
AI-written summary · about
chapters (14)
- 0:00Introduction to memory representation
- 1:22Firmware and memory maps
- 3:32Architecture-specific memory views
- 5:45Problems with current representations
- 10:28Need for a generic memory representation
- 12:15Memblock and its limitations
- 14:03FDT and memory representation
- 15:39Proposal to rename memblock
- 16:02Memory hot-plug mechanisms
- 17:52Kexec and memory maps across architectures
- 20:26Kexec memory handling details
- 21:13Hot-plug memory in Kexec context
- 22:19FDT and memory hot-plug approaches
- 23:45Closing remarks
related talks
31mBoot Time Memory Management
46mHighmem deprecation planning
38mDeferred Memblocks Init for Boot Time Reduction
30mdrm and cgroup memory management - two great tastes
30miommu page table consolidation and iommufd
01h 05mMicroconference for resctrl
16mUnifying KVM API for protected VM and utilities
43mpkernfs: Persisting guest memory and kernel/device state safely...