From: Andy Whitcroft <apw@shadowen.org>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, agl@us.ibm.com, wli@holomorphy.com,
kenchen@google.com, dwg@au1.ibm.com, andi@firstfloor.org,
Mel Gorman <mel@csn.ul.ie>,
dean@arctic.org
Subject: [PATCH 0/3] MAP_NORESERVE for hugetlb mappings V1
Date: Wed, 7 May 2008 21:24:26 +0100 [thread overview]
Message-ID: <exportbomb.1210191800@pinky> (raw)
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.
All against 2.6.25-mm1 with Mel's private reservation patches:
Subject: Guarantee faults for processes that call mmap(MAP_PRIVATE)
on hugetlbfs v2
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 majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2008-05-07 20:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-07 20:24 Andy Whitcroft [this message]
2008-05-07 20:24 ` [PATCH 1/3] record MAP_NORESERVE status on vmas and fix small page mprotect reservations Andy Whitcroft
2008-05-07 20:24 ` [PATCH 2/3] hugetlb-move-reservation-region-support-earlier Andy Whitcroft
2008-05-07 20:25 ` [PATCH 3/3] hugetlb-allow-huge-page-mappings-to-be-created-without-reservations Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=exportbomb.1210191800@pinky \
--to=apw@shadowen.org \
--cc=agl@us.ibm.com \
--cc=andi@firstfloor.org \
--cc=dean@arctic.org \
--cc=dwg@au1.ibm.com \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).