linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Michal Hocko <mhocko@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [RFC 0/3] hugetlbfs: optionally reserve all fs pages at mount time
Date: Fri, 6 Mar 2015 13:14:43 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1503061312170.10330@chino.kir.corp.google.com> (raw)
In-Reply-To: <54F9F8F1.4020203@oracle.com>

On Fri, 6 Mar 2015, Mike Kravetz wrote:

> Thanks for the CONFIG_CGROUP_HUGETLB suggestion, however I do not
> believe this will be a satisfactory solution for my usecase.  As you
> point out, cgroups could be set up (by a sysadmin) for every hugetlb
> user/application.  In this case, the sysadmin needs to have knowledge
> of every huge page user/application and configure appropriately.
> 
> I was approaching this from the point of view of the application.  The
> application wants the guarantee of a minimum number of huge pages,
> independent of other users/applications.  The "reserve" approach allows
> the application to set aside those pages at initialization time.  If it
> can not get the pages it needs, it can refuse to start, or configure
> itself to use less, or take other action.
> 

Would it be too difficult to modify the application to mmap() the 
hugepages at startup so they are no longer free in the global pool but 
rather get marked as reserved so other applications cannot map them?  That 
should return MAP_FAILED if there is an insufficient number of hugepages 
available to be reserved (HugePages_Rsvd in /proc/meminfo).

--
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>

  reply	other threads:[~2015-03-06 21:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 22:58 Mike Kravetz
2015-02-27 22:58 ` [RFC 1/3] hugetlbfs: add reserved mount fields to subpool structure Mike Kravetz
2015-02-27 22:58 ` Mike Kravetz
2015-03-02 23:10   ` Andrew Morton
2015-03-03  1:20     ` Mike Kravetz
2015-02-27 22:58 ` [RFC 2/3] hugetlbfs: coordinate global and subpool reserve accounting Mike Kravetz
2015-03-02 23:10   ` Andrew Morton
2015-03-03  1:30     ` Mike Kravetz
2015-02-27 22:58 ` Mike Kravetz
2015-02-27 22:58 ` [RFC 3/3] hugetlbfs: accept subpool reserved option and setup accordingly Mike Kravetz
2015-03-02 23:10   ` Andrew Morton
2015-03-03  1:36     ` Mike Kravetz
2015-03-02 23:10 ` [RFC 0/3] hugetlbfs: optionally reserve all fs pages at mount time Andrew Morton
2015-03-03  1:18   ` Mike Kravetz
2015-03-06 15:10     ` Michal Hocko
2015-03-06 18:58       ` Mike Kravetz
2015-03-06 21:14         ` David Rientjes [this message]
2015-03-06 21:32           ` 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=alpine.DEB.2.10.1503061312170.10330@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mike.kravetz@oracle.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