MAP_NORESERVE for hugetlb mappings V3
Get series with b4
b4 am exportbomb.1211929624@pinkyVersions newest first
- v1 Latest3 patches 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | record MAP_NORESERVE status on vmas and fix small page mprotect reservationsinclude/ mm/ mm/ | +6 | 0 replies | |
| 2/3 | hugetlb-move-reservation-region-support-earliermm/ | +121 | 1 reply | |
| 3/3 | hugetlb-allow-huge-page-mappings-to-be-created-without-reservationsmm/ | +55 | 2 replies |
Reviews trailers per patch
1 of 3 patches has a Reviewed-by or Acked-by.
| Patch | Adam Litke |
|---|---|
| 1/3 | |
| 2/3 | A-b |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/3] MAP_NORESERVE for hugetlb mappings V3
This stack is a rebase of the V2 stack onto 2.6.26-rc2-mm1 with Mel's "Guarantee faults for processes that call mmap(MAP_PRIVATE) on hugetlbfs v4" applied. This stack allows map users to opt-out of the new stricter over-commit handling should those semantics be unsuitable, using the standard MAP_NORESERVE mmap flag.
This stack should be seen as complementary to Mel's stack, which it is dependant on.
Please consider for -mm.
-apw
===
With Mel's hugetlb private reservation support patches applied, strict overcommit semantics are applied to both shared and private huge page mappings. This can be a problem if an application relied on unlimited overcommit semantics for private mappings. An example of this would be an application which maps a huge area with the intention of using it very sparsely. These application would benefit from being able to opt-out of the strict overcommit. It should be noted that prior to hugetlb supporting demand faulting all mappings were fully populated and so applications of this type should be rare.
This patch stack implements the MAP_NORESERVE mmap() flag for huge page mappings. This flag has the same meaning as for small page mappings, suppressing reservations for that mapping.
The stack is made up of three patches:
record-MAP_NORESERVE-status-on-vmas-and-fix-small-page-mprotect-reservations --
currently when we mprotect a private MAP_NORESERVE mapping read-write we have no choice but to create a reservation for it. Fix that by introducing a VM_NORESERVE vma flag and checking it before allocating reserve.
hugetlb-move-reservation-region-support-earlier -- simply moves the
reservation region support so it can be used earlier.
hugetlb-allow-huge-page-mappings-to-be-created-without-reservations --
use the new VM_NORESERVE flag to control the application of hugetlb reservations to new mappings.
This has been functionally tested with a hugetlb reservation test suite.
All against 2.6.26-rc2-mm1 with Mel's private reservation patches:
Subject: Guarantee faults for processes that call mmap(MAP_PRIVATE)
on hugetlbfs v4
Thanks to Mel Gorman for reviewing a number of early versions of these patches.
-apw
--
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>