All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: bill4carson <bill4carson@gmail.com>
Cc: linux-mm@kvack.org, mgorman@suse.de,
	kamezawa.hiroyu@jp.fujitsu.com, dhillf@gmail.com
Subject: Re: [RFC PATCH 5/6] hugetlbfs: Add controller support for private mapping
Date: Fri, 17 Feb 2012 13:35:06 +0530	[thread overview]
Message-ID: <87aa4hevgt.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F3DE424.3010301@gmail.com>

On Fri, 17 Feb 2012 13:22:44 +0800, bill4carson <bill4carson@gmail.com> wrote:
> 
> 
> On 2012年02月11日 05:36, Aneesh Kumar K.V wrote:
> > From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
> >
> > HugeTLB controller is different from a memory controller in that we charge
> > controller during mmap() time and not fault time. This make sure userspace
> > can fallback to non-hugepage allocation when mmap fails due to controller
> > limit.
> >
> > For private mapping we always charge/uncharge from the current task cgroup.
> > Charging happens during mmap(2) and uncharge happens during the
> > vm_operations->close when resv_map refcount reaches zero. The uncharge count
> > is stored in struct resv_map. For child task after fork the charging happens
> > during fault time in alloc_huge_page. We also need to make sure for private
> > mapping each vma for hugeTLB mapping have struct resv_map allocated so that we
> > can store the uncharge count in resv_map.
> >
> > Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
> > ---
> >   fs/hugetlbfs/hugetlb_cgroup.c  |   50 ++++++++++++++++++++++++++++++++
> >   include/linux/hugetlb.h        |    7 ++++
> >   include/linux/hugetlb_cgroup.h |   16 ++++++++++
> >   mm/hugetlb.c                   |   62 ++++++++++++++++++++++++++++++++--------
> >   4 files changed, 123 insertions(+), 12 deletions(-)
> >
> > diff --git a/fs/hugetlbfs/hugetlb_cgroup.c b/fs/hugetlbfs/hugetlb_cgroup.c
> > index c478fb0..f828fb2 100644
> > --- a/fs/hugetlbfs/hugetlb_cgroup.c
> > +++ b/fs/hugetlbfs/hugetlb_cgroup.c
> > @@ -458,3 +458,53 @@ long  hugetlb_truncate_cgroup_charge(struct hstate *h,
> >   	}
> >   	return chg;
> >   }
> > +
> > +int hugetlb_priv_page_charge(struct resv_map *map, struct hstate *h, long chg)
> > +{
> > +	long csize;
> > +	int idx, ret;
> > +	struct hugetlb_cgroup *h_cg;
> > +	struct res_counter *fail_res;
> > +
> > +	/*
> > +	 * Get the task cgroup within rcu_readlock and also
> > +	 * get cgroup reference to make sure cgroup destroy won't
> > +	 * race with page_charge. We don't allow a cgroup destroy
> > +	 * when the cgroup have some charge against it
> > +	 */
> > +	rcu_read_lock();
> > +	h_cg = task_hugetlbcgroup(current);
> > +	css_get(&h_cg->css);
> > +	rcu_read_unlock();
> > +
> > +	if (hugetlb_cgroup_is_root(h_cg)) {
> > +		ret = chg;
> > +		goto err_out;
> > +	}
> > +
> > +	csize = chg * huge_page_size(h);
> > +	idx = h - hstates;
> > +	ret = res_counter_charge(&h_cg->memhuge[idx], csize,&fail_res);
> > +	if (!ret) {
> > +		map->nr_pages[idx] += chg<<  huge_page_order(h);
> > +		ret = chg;
> > +	}
> > +err_out:
> > +	css_put(&h_cg->css);
> > +	return ret;
> > +}
> > +
> > +void hugetlb_priv_page_uncharge(struct resv_map *map, int idx, int nr_pages)
> > +{
> > +	struct hugetlb_cgroup *h_cg;
> > +	unsigned long csize = nr_pages * PAGE_SIZE;
> > +
> > +	rcu_read_lock();
> > +	h_cg = task_hugetlbcgroup(current);
> > +	if (!hugetlb_cgroup_is_root(h_cg)) {
> > +		res_counter_uncharge(&h_cg->memhuge[idx], csize);
> > +		map->nr_pages[idx] -= nr_pages;
> > +	}
> > +	rcu_read_unlock();
> > +	return;
> > +}
> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index 4392b6a..e2ba381 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -233,6 +233,12 @@ struct hstate {
> >   	char name[HSTATE_NAME_LEN];
> >   };
> >
> > +struct resv_map {
> > +	struct kref refs;
> > +	int nr_pages[HUGE_MAX_HSTATE];
> > +	struct list_head regions;
> > +};
> > +
> 
> Please put resv_map after HUGE_MAX_HSTATE definition,
> otherwise it will break on non-x86 arches, which has no
> HUGE_MAX_HSTATE definition.
> 
> 
> #ifndef HUGE_MAX_HSTATE
> #define HUGE_MAX_HSTATE 1
> #endif
> 
> +struct resv_map {
> +	struct kref refs;
> +	int nr_pages[HUGE_MAX_HSTATE];
> +	struct list_head regions;
> +};
> 
> 
> 
> 

Will do in the next iteration.

Thanks for the review
-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-02-17  8:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10 21:36 [RFC PATCH 0/6] hugetlbfs: Add cgroup resource controller for hugetlbfs Aneesh Kumar K.V
2012-02-10 21:36 ` [RFC PATCH 1/6] hugetlb: Add a new hugetlb cgroup Aneesh Kumar K.V
2012-02-10 21:36 ` [RFC PATCH 2/6] hugetlbfs: Add usage and max usage files to " Aneesh Kumar K.V
2012-02-10 21:36 ` [RFC PATCH 3/6] hugetlbfs: Add new region handling functions Aneesh Kumar K.V
2012-02-10 21:36 ` [RFC PATCH 4/6] hugetlbfs: Add controller support for shared mapping Aneesh Kumar K.V
2012-02-10 21:36 ` [RFC PATCH 5/6] hugetlbfs: Add controller support for private mapping Aneesh Kumar K.V
2012-02-17  5:22   ` bill4carson
2012-02-17  8:05     ` Aneesh Kumar K.V [this message]
2012-02-10 21:36 ` [RFC PATCH 6/6] hugetlbfs: Switch to new region APIs Aneesh Kumar K.V
2012-02-11 12:37 ` [RFC PATCH 0/6] hugetlbfs: Add cgroup resource controller for hugetlbfs Hillf Danton
2012-02-12 17:44   ` Aneesh Kumar K.V
2012-02-14  6:58 ` KAMEZAWA Hiroyuki
2012-02-17  8:00   ` Aneesh Kumar K.V
2012-02-17  8:03   ` Aneesh Kumar K.V
2012-02-17  8:03     ` Aneesh Kumar K.V

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=87aa4hevgt.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=bill4carson@gmail.com \
    --cc=dhillf@gmail.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.