Virtual Compound Page Support V3
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest14 patches 72 repliesIn review
Changes in v1 from the cover letter
- Complete support for all compound functions for virtual compound pages (including the compound_nth_page() necessary for LBS mmap support)
- Fix various bugs
- Fix i386 build
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/14 | vcompound: Return page array on vunmapinclude/ mm/ | +23 | 0 replies | |
| 2/14 | vcompound: pageflags: Add PageVcompound()include/ | +18 | 0 replies | |
| 3/14 | vmallocinfo: Support display of vcompound for a virtual compound pageinclude/ mm/ | +4 | 2 replies | |
| 4/14 | vcompound: Core pieceinclude/ mm/ | +211 | 2 replies | |
| 5/14 | vcompound: Debugging aidlib/ mm/ | +26 | 0 replies | |
| 6/14 | vcompound: Virtual fallback for sparsememmm/ | +2 | 0 replies | |
| 7/14 | vcompound: bit waitqueue supportkernel/ | +2 | 0 replies | |
| 8/14 | vcompound: Fallback for zone wait tablemm/ | +2 | 0 replies | |
| 9/14 | vcompound: crypto: Fallback for temporary order 2 allocationcrypto/ | +2 | 0 replies | |
| 10/14 | vcompound: slub: Use for buffer to correlate allocation addressesmm/ | +3 | 0 replies | |
| 11/14 | vcompound: Fallbacks for order 1 stack allocations on IA64 and x86include/ include/ include/ | +8 | 51 replies | |
| 12/14 | vcompound: Avoid vmalloc in e1000 driverdrivers/ drivers/ | +17 | 1 reply | |
| 13/14 | vcompound: Use vcompound for swap_mapmm/ | +4 | 7 replies | |
| 14/14 | vcompound: Avoid vmalloc for ehash_locksinclude/ | +3 | 6 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [00/14] Virtual Compound Page Support V3
Allocations of larger pages are not reliable in Linux. If larger pages have to be allocated then one faces various choices of allowing graceful fallback or using vmalloc with a performance penalty due to the use of a page table. Virtual Compound pages are
a simple solution out of this dilemma.
A virtual compound allocation means that there will be first of all an attempt to satisfy the request with physically contiguous memory. If that is not possible then a virtually contiguous memory will be created.
This has two advantages:
1. Current uses of vmalloc can be converted to allocate virtual compounds instead. In most cases physically contiguous memory can be used which avoids the vmalloc performance penalty. See f.e. the e1000 driver patch.
2. Uses of higher order allocations (stacks, buffers etc) can be converted to use virtual compounds instead. Physically contiguous memory will still be used for those higher order allocs in general but the system can degrade to the use of vmalloc should memory become heavily fragmented.
There is a compile time option to switch on fallback for testing purposes. Virtually mapped mmemory may behave differently and the CONFIG_FALLBACK_ALWAYS option will ensure that the code is tested to deal with virtual memory.
V2->V3:
- Put the code into mm/vmalloc.c and leave the page allocator alone.
- Add a series of examples where virtual compound pages can be used.
- Diffed on top of the page flags and the vmalloc info patches already in mm.
- Simplify things by omitting some of the more complex code that used to be in there.
V1->V2
- Remove some cleanup patches and the SLUB patches from this set.
- Transparent vcompound support through page_address() and virt_to_head_page().
- Additional use cases.
- Factor the code better for an easier read
- Add configurable stack size.
- Follow up on various suggestions made for V1
RFC->V1
- Complete support for all compound functions for virtual compound pages (including the compound_nth_page() necessary for LBS mmap support)
- Fix various bugs
- Fix i386 build
Signature · 5 lines
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>