lkml.org 
[lkml]   [2012]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH -V8 12/16] hugetlb/cgroup: Add support for cgroup removal
Date
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:

> (2012/06/09 17:59), Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
>>
>> This patch add support for cgroup removal. If we don't have parent
>> cgroup, the charges are moved to root cgroup.
>>
>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
>
> I'm sorry if already pointed out....
>
>> ---
>> mm/hugetlb_cgroup.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 79 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
>> index 48efd5a..9458fe3 100644
>> --- a/mm/hugetlb_cgroup.c
>> +++ b/mm/hugetlb_cgroup.c
>> @@ -99,10 +99,87 @@ static void hugetlb_cgroup_destroy(struct cgroup *cgroup)
>> kfree(h_cgroup);
>> }
>>
>> +
>> +static int hugetlb_cgroup_move_parent(int idx, struct cgroup *cgroup,
>> + struct page *page)
>> +{
>> + int csize;
>> + struct res_counter *counter;
>> + struct res_counter *fail_res;
>> + struct hugetlb_cgroup *page_hcg;
>> + struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_cgroup(cgroup);
>> + struct hugetlb_cgroup *parent = parent_hugetlb_cgroup(cgroup);
>> +
>> + if (!get_page_unless_zero(page))
>> + goto out;
>
> It seems this doesn't necessary...this is under hugetlb_lock().

already updated.

>
>> +
>> + page_hcg = hugetlb_cgroup_from_page(page);
>> + /*
>> + * We can have pages in active list without any cgroup
>> + * ie, hugepage with less than 3 pages. We can safely
>> + * ignore those pages.
>> + */
>> + if (!page_hcg || page_hcg != h_cg)
>> + goto err_out;
>> +
>> + csize = PAGE_SIZE<< compound_order(page);
>> + if (!parent) {
>> + parent = root_h_cgroup;
>> + /* root has no limit */
>> + res_counter_charge_nofail(&parent->hugepage[idx],
>> + csize,&fail_res);
> ^^^
> space ?

I don't have code this way locally, may be a mail client error ?

>
>> + }
>> + counter =&h_cg->hugepage[idx];
>> + res_counter_uncharge_until(counter, counter->parent, csize);
>> +
>> + set_hugetlb_cgroup(page, parent);
>> +err_out:
>> + put_page(page);
>> +out:
>> + return 0;
>> +}
>> +
>> +/*
>> + * Force the hugetlb cgroup to empty the hugetlb resources by moving them to
>> + * the parent cgroup.
>> + */
>> static int hugetlb_cgroup_pre_destroy(struct cgroup *cgroup)
>> {
>> - /* We will add the cgroup removal support in later patches */
>> - return -EBUSY;
>> + struct hstate *h;
>> + struct page *page;
>> + int ret = 0, idx = 0;
>> +
>> + do {
>> + if (cgroup_task_count(cgroup) ||
>> + !list_empty(&cgroup->children)) {
>> + ret = -EBUSY;
>> + goto out;
>> + }

Is this check going to moved to higher levels ? Do we still need
this. Or will that happen when pred_destroy becomes void ?

>
>> + /*
>> + * If the task doing the cgroup_rmdir got a signal
>> + * we don't really need to loop till the hugetlb resource
>> + * usage become zero.
>> + */
>> + if (signal_pending(current)) {
>> + ret = -EINTR;
>> + goto out;
>> + }
>
> I'll post a patch to remove this check from memcg because memcg's rmdir
> always succeed now. So, could you remove this ?

Will drop this

>
>
>> + for_each_hstate(h) {
>> + spin_lock(&hugetlb_lock);
>> + list_for_each_entry(page,&h->hugepage_activelist, lru) {
>> + ret = hugetlb_cgroup_move_parent(idx, cgroup, page);
>> + if (ret) {
>
> When 'ret' should be !0 ?
> If hugetlb_cgroup_move_parent() always returns 0, the check will not be necessary.
>

I will make this void funciton.

-aneesh



\
 
 \ /
  Last update: 2012-06-12 13:41    [W:0.151 / U:5.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site