linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, mgorman@suse.de,
	kamezawa.hiroyu@jp.fujitsu.com, dhillf@gmail.com,
	aarcange@redhat.com, mhocko@suse.cz, hannes@cmpxchg.org,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH -V3 0/8] memcg: Add memcg extension to control HugeTLB allocation
Date: Wed, 14 Mar 2012 18:31:09 +0530	[thread overview]
Message-ID: <87fwdb8hgq.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120313144930.284228c4.akpm@linux-foundation.org>

On Tue, 13 Mar 2012 14:49:30 -0700, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 13 Mar 2012 12:37:04 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
> > This patchset implements a memory controller extension to control
> > HugeTLB allocations.
> 
> Well, why?  What are the use cases?  Who is asking for this?  Why do
> they need it and how will they use it?  etcetera.
> 
> Please explain, with some care, why you think we should add this
> feature to the kernel.  So that others can assess whether the value it
> adds is worth the cost of adding and maintaining it.
> 

The goal is to control how many HugeTLB pages a group of task can
allocate. It can be looked at as an extension of the existing quota
interface which limits the number of HugeTLB pages per hugetlbfs
superblock. HPC job scheduler requires jobs to specify their resource
requirements in the job file. Once their requirements can be met,
job schedulers like (SLURM) will schedule the job. We need to make sure
that the jobs won't consume more resources than requested. If they do
we should error out or kill the application.

-aneesh

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-03-14 13:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13  7:07 [PATCH -V3 0/8] memcg: Add memcg extension to control HugeTLB allocation Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 1/8] hugetlb: rename max_hstate to hugetlb_max_hstate Aneesh Kumar K.V
2012-03-13 13:13   ` Hillf Danton
2012-03-13  7:07 ` [PATCH -V3 2/8] memcg: Add HugeTLB extension Aneesh Kumar K.V
2012-03-13 13:28   ` Glauber Costa
2012-03-13 13:42     ` Glauber Costa
2012-03-13 21:33   ` Andrew Morton
2012-03-14 10:21     ` Aneesh Kumar K.V
2012-03-14 23:43       ` Andrew Morton
2012-03-13  7:07 ` [PATCH -V3 3/8] hugetlb: add charge/uncharge calls for HugeTLB alloc/free Aneesh Kumar K.V
2012-03-13 13:20   ` Hillf Danton
2012-03-14 10:22     ` Aneesh Kumar K.V
2012-03-13 13:31   ` Glauber Costa
2012-03-14 10:41     ` Aneesh Kumar K.V
2012-03-13 21:36   ` Andrew Morton
2012-03-14 10:47     ` Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 4/8] memcg: track resource index in cftype private Aneesh Kumar K.V
2012-03-13 13:34   ` Glauber Costa
2012-03-14 10:48     ` Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 5/8] hugetlbfs: Add memcg control files for hugetlbfs Aneesh Kumar K.V
2012-03-13 21:42   ` Andrew Morton
2012-03-14 11:10     ` Aneesh Kumar K.V
2012-03-14 11:35       ` Andrew Morton
2012-03-14 15:57         ` Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 6/8] hugetlbfs: Add a list for tracking in-use HugeTLB pages Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 7/8] memcg: move HugeTLB resource count to parent cgroup on memcg removal Aneesh Kumar K.V
2012-03-13 21:47   ` Andrew Morton
2012-03-14 12:22     ` Aneesh Kumar K.V
2012-03-13  7:07 ` [PATCH -V3 8/8] memcg: Add memory controller documentation for hugetlb management Aneesh Kumar K.V
2012-03-13 21:49 ` [PATCH -V3 0/8] memcg: Add memcg extension to control HugeTLB allocation Andrew Morton
2012-03-14 13:01   ` Aneesh Kumar K.V [this message]

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=87fwdb8hgq.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=dhillf@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    /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).