RFC Larger Order Protection V1
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 patches 24 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | Protect larger order pages from breaking upinclude/ include/ mm/ +1 more | +193 | 21 replies | |
| 2/2 | Page order diagnosticsfs/ include/ include/ +3 more | +84 | 2 replies |
Reviews trailers per patch
None of the 2 patches has a Reviewed-by or Acked-by.
| Patch | Thomas Schoebel-Theuer |
|---|---|
| 1/2 | Idea-by |
| 2/2 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC 0/2] Larger Order Protection V1
We have discussed for years ways to create more reliable ways to allocate large contiguous memory segments and to avoid fragmentation. This is an ad hoc scheme based on reservation of higher order pages in the page allocator. It is fully transparent and integrated into the page allocator.
This approach goes back to the meeting on contiguous memory at the Plumbers conference in 2017 and the effort by Guy and Mike Kravetz to establish and API to map contiguous memory segments into user space. Reservations will allow the contiguous memory allocations to work even after the system has run for a considerable time.
Contiguous memory is also important for general system performance. F.e. slab allocators can be made to use large frames in order to optimize performance. See patch 1.
Other use cases are jumbo frames or device driver specific allocations.
For more on this see Mike Kravetz patches in particular
Mike Kravetz MMAP CONTIG flag support at
https://lkml.org/lkml/2017/10/3/992
--
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>