VM followup: page migration and fragmentation avoidance
Posted Nov 25, 2005 11:30 UTC (Fri) by
farnz (subscriber, #17727)
In reply to:
VM followup: page migration and fragmentation avoidance by markryde
Parent article:
VM followup: page migration and fragmentation avoidance
Uses I can think of (other people will no doubt correct me when I've got things wrong):
- Memory hotplug. This needs a guarantee that pages will move off the chips you're about to unplug, so these patches are only a beginning for that use.
- Driver DMA buffer allocation. Some devices can't do scatter-gather DMA (thankfully these are getting rare), so need to allocate large buffers as a single continguous lump. More common is 32-bit devices on a 64-bit system without an IOMMU; rather than use bounce buffering, you can migrate pages in and out of the DMA32 zone and get the same effect. This isn't necessarily a win though.
- Large page size support - migrating pages allows you to defragment memory. There's little support for this in Linux at the moment (hugetlbfs only), but the idea is to merge lots of small pages into bigger ones where possible. For example, x86 hardware supports a 2MB or 4MB page size in addition to the normal 4K page size; some MIPS and IA-64 hardware support 4K, 16K and 64K pages. For now, you can access large pages (subject to physical memory fragmentation) via the hugetlb code; in theory, Linux could be extended to support large pages transparently (defragment physical memory so that a large page sized virtual allocation gets backed by large pages). This gets you more bytes in the TLB (as the TLB counts pages, not byte addresses), and smaller page tables; the question is whether the increased code complexity (and corresponding bug opportunity) outweighs the potential gains.
Just a few uses to think about, anyway.
(
Log in to post comments)