From: Mike Kravetz <mike.kravetz@oracle.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andi Kleen <andi@firstfloor.org>,
David Rientjes <rientjes@google.com>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: [PATCH V3 0/4] hugetlbfs: add min_size filesystem mount option
Date: Fri, 20 Mar 2015 13:47:06 -0700 [thread overview]
Message-ID: <cover.1426880499.git.mike.kravetz@oracle.com> (raw)
hugetlbfs allocates huge pages from the global pool as needed. Even if
the global pool contains a sufficient number pages for the filesystem
size at mount time, those global pages could be grabbed for some other
use. As a result, filesystem huge page allocations may fail due to lack
of pages.
Applications such as a database want to use huge pages for performance
reasons. hugetlbfs filesystem semantics with ownership and modes work
well to manage access to a pool of huge pages. However, the application
would like some reasonable assurance that allocations will not fail due
to a lack of huge pages. At application startup time, the application
would like to configure itself to use a specific number of huge pages.
Before starting, the application can check to make sure that enough huge
pages exist in the system global pools. However, there are no guarantees
that those pages will be available when needed by the application. What
the application wants is exclusive use of a subset of huge pages.
Add a new hugetlbfs mount option 'min_size=<value>' to indicate that
the specified number of pages will be available for use by the filesystem.
At mount time, this number of huge pages will be reserved for exclusive
use of the filesystem. If there is not a sufficient number of free pages,
the mount will fail. As pages are allocated to and freeed from the
filesystem, the number of reserved pages is adjusted so that the specified
minimum is maintained.
V3:
Struct init and comment cleanup as suggested by Andrew Morton
Cleaned up size option argument parsing to hopefully be more clear
Fixed kbuild warning introduced in V2
Made documentation more explicit and added descriptions for 'existing'
pagesize options and ability to specify size as a percent
V2:
Added ability to specify minimum size. Suggsted by David Rientjes
V1:
Comments from RFC addressed/incorporated
Mike Kravetz (4):
hugetlbfs: add minimum size tracking fields to subpool structure
hugetlbfs: add minimum size accounting to subpools
hugetlbfs: accept subpool min_size mount option and setup accordingly
hugetlbfs: document min_size mount option and cleanup
Documentation/vm/hugetlbpage.txt | 31 +++++---
fs/hugetlbfs/inode.c | 90 ++++++++++++++++++-----
include/linux/hugetlb.h | 11 ++-
mm/hugetlb.c | 151 +++++++++++++++++++++++++++++++--------
4 files changed, 224 insertions(+), 59 deletions(-)
--
2.1.0
--
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:[~2015-03-20 20:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 20:47 Mike Kravetz [this message]
2015-03-20 20:47 ` [PATCH V3 1/4] hugetlbfs: add minimum size tracking fields to subpool structure Mike Kravetz
2015-03-20 20:47 ` [PATCH V3 2/4] hugetlbfs: add minimum size accounting to subpools Mike Kravetz
2015-03-20 20:47 ` [PATCH V3 3/4] hugetlbfs: accept subpool min_size mount option and setup accordingly Mike Kravetz
2015-03-20 20:47 ` [PATCH V3 4/4] hugetlbfs: document min_size mount option and cleanup Mike Kravetz
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=cover.1426880499.git.mike.kravetz@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave@stgolabs.net \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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).