From: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
To: "Aneesh Kumar K.V"
<aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
mgorman-l3A5Bk7waGM@public.gmane.org,
dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
mhocko-AlSwsSmVLrQ@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH -V5 12/14] memcg: move HugeTLB resource count to parent cgroup on memcg removal
Date: Tue, 10 Apr 2012 15:55:33 +0900 [thread overview]
Message-ID: <4F83D965.4040506@jp.fujitsu.com> (raw)
In-Reply-To: <87ty0tcjhx.fsf-6yE53ggjAfyqSkle7U1LjlaTQe2KTcn/@public.gmane.org>
(2012/04/09 19:00), Aneesh Kumar K.V wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> writes:
>
>> (2012/04/07 3:50), Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>>
>>> This add support for memcg removal with HugeTLB resource usage.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>
>>
>> Hmm
>>
>>
>
> ....
> ...
>
>>> + csize = PAGE_SIZE << compound_order(page);
>>> + /*
>>> + * uncharge from child and charge the parent. If we have
>>> + * use_hierarchy set, we can never fail here. In-order to make
>>> + * sure we don't get -ENOMEM on parent charge, we first uncharge
>>> + * the child and then charge the parent.
>>> + */
>>> + if (parent->use_hierarchy) {
>>
>>
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + if (!mem_cgroup_is_root(parent))
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>
>>
>> Ah, why is !mem_cgroup_is_root() checked ? no res_counter update for
>> root cgroup ?
>
> My mistake. Earlier version of the patch series didn't charge/uncharge the root
> cgroup during different operations. Later as per your review I updated
> the charge/uncharge path to charge root cgroup. I missed to update this code.
>
>>
>> I think it's better to have res_counter_move_parent()...to do ops in atomic.
>> (I'll post a patch for that for my purpose). OR, just ignore res->usage if
>> parent->use_hierarchy == 1.
>>
>> uncharge->charge will have a race.
>
>
>
> How about the below
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7b6e79a..5b4bc98 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3351,24 +3351,24 @@ int mem_cgroup_move_hugetlb_parent(int idx, struct cgroup *cgroup,
>
> csize = PAGE_SIZE << compound_order(page);
> /*
> - * uncharge from child and charge the parent. If we have
> - * use_hierarchy set, we can never fail here. In-order to make
> - * sure we don't get -ENOMEM on parent charge, we first uncharge
> - * the child and then charge the parent.
> + * If we have use_hierarchy set we can never fail here. So instead of
> + * using res_counter_uncharge use the open-coded variant which just
> + * uncharge the child res_counter. The parent will retain the charge.
> */
> if (parent->use_hierarchy) {
> - res_counter_uncharge(&memcg->hugepage[idx], csize);
> - if (!mem_cgroup_is_root(parent))
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> + unsigned long flags;
> + struct res_counter *counter;
> +
> + counter = &memcg->hugepage[idx];
> + spin_lock_irqsave(&counter->lock, flags);
> + res_counter_uncharge_locked(counter, csize);
Hm, uncharge_locked is not propagated to parent, I see.
Ok, it seems to work...but please add enough comment here. Or define
res_counter_move_parent().
> + spin_unlock_irqrestore(&counter->lock, flags);
> } else {
> - if (!mem_cgroup_is_root(parent)) {
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> - if (ret) {
> - ret = -EBUSY;
> - goto err_out;
> - }
> + ret = res_counter_charge(&parent->hugepage[idx],
> + csize, &fail_res);
> + if (ret) {
> + ret = -EBUSY;
> + goto err_out;
> }
> res_counter_uncharge(&memcg->hugepage[idx], csize);
> }
>
>
>>
>>> + } else {
>>> + if (!mem_cgroup_is_root(parent)) {
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>> + if (ret) {
>>> + ret = -EBUSY;
>>> + goto err_out;
>>> + }
>>> + }
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + }
>>
>>
>> Just a notice. Recently, Tejun changed failure of pre_destory() to show WARNING.
>> Then, I'd like to move the usage to the root cgroup if use_hierarchy=0.
>> Will it work for you ?
>
> That should work.
>
ok, I'll go ahead in that way.
>
>>
>>> + /*
>>> + * caller should have done css_get
>>> + */
>>
>>
>> Could you explain meaning of this comment ?
>>
>
> inherited from mem_cgroup_move_account. I guess it means css cannot go
> away at this point. We have done a css_get on the child. For a generic
> move_account function may be the comment is needed. I guess in our case
> the comment is redundant ?
>
Ah, IIUC, this code is hugetlb version of mem_cgroup_move_parent().
At move_parent(), we don't need to take care of css counting because we're
moving from an exisiting cgroup to an cgroup which cannot be destroyed.
(move_account() is function to move account between arbitrary cgroup.)
So, yes, please remove comment.
Thanks,
-Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, mgorman@suse.de, dhillf@gmail.com,
aarcange@redhat.com, mhocko@suse.cz, akpm@linux-foundation.org,
hannes@cmpxchg.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [PATCH -V5 12/14] memcg: move HugeTLB resource count to parent cgroup on memcg removal
Date: Tue, 10 Apr 2012 15:55:33 +0900 [thread overview]
Message-ID: <4F83D965.4040506@jp.fujitsu.com> (raw)
In-Reply-To: <87ty0tcjhx.fsf@skywalker.in.ibm.com>
(2012/04/09 19:00), Aneesh Kumar K.V wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
>
>> (2012/04/07 3:50), Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> This add support for memcg removal with HugeTLB resource usage.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>>
>> Hmm
>>
>>
>
> ....
> ...
>
>>> + csize = PAGE_SIZE << compound_order(page);
>>> + /*
>>> + * uncharge from child and charge the parent. If we have
>>> + * use_hierarchy set, we can never fail here. In-order to make
>>> + * sure we don't get -ENOMEM on parent charge, we first uncharge
>>> + * the child and then charge the parent.
>>> + */
>>> + if (parent->use_hierarchy) {
>>
>>
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + if (!mem_cgroup_is_root(parent))
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>
>>
>> Ah, why is !mem_cgroup_is_root() checked ? no res_counter update for
>> root cgroup ?
>
> My mistake. Earlier version of the patch series didn't charge/uncharge the root
> cgroup during different operations. Later as per your review I updated
> the charge/uncharge path to charge root cgroup. I missed to update this code.
>
>>
>> I think it's better to have res_counter_move_parent()...to do ops in atomic.
>> (I'll post a patch for that for my purpose). OR, just ignore res->usage if
>> parent->use_hierarchy == 1.
>>
>> uncharge->charge will have a race.
>
>
>
> How about the below
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7b6e79a..5b4bc98 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3351,24 +3351,24 @@ int mem_cgroup_move_hugetlb_parent(int idx, struct cgroup *cgroup,
>
> csize = PAGE_SIZE << compound_order(page);
> /*
> - * uncharge from child and charge the parent. If we have
> - * use_hierarchy set, we can never fail here. In-order to make
> - * sure we don't get -ENOMEM on parent charge, we first uncharge
> - * the child and then charge the parent.
> + * If we have use_hierarchy set we can never fail here. So instead of
> + * using res_counter_uncharge use the open-coded variant which just
> + * uncharge the child res_counter. The parent will retain the charge.
> */
> if (parent->use_hierarchy) {
> - res_counter_uncharge(&memcg->hugepage[idx], csize);
> - if (!mem_cgroup_is_root(parent))
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> + unsigned long flags;
> + struct res_counter *counter;
> +
> + counter = &memcg->hugepage[idx];
> + spin_lock_irqsave(&counter->lock, flags);
> + res_counter_uncharge_locked(counter, csize);
Hm, uncharge_locked is not propagated to parent, I see.
Ok, it seems to work...but please add enough comment here. Or define
res_counter_move_parent().
> + spin_unlock_irqrestore(&counter->lock, flags);
> } else {
> - if (!mem_cgroup_is_root(parent)) {
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> - if (ret) {
> - ret = -EBUSY;
> - goto err_out;
> - }
> + ret = res_counter_charge(&parent->hugepage[idx],
> + csize, &fail_res);
> + if (ret) {
> + ret = -EBUSY;
> + goto err_out;
> }
> res_counter_uncharge(&memcg->hugepage[idx], csize);
> }
>
>
>>
>>> + } else {
>>> + if (!mem_cgroup_is_root(parent)) {
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>> + if (ret) {
>>> + ret = -EBUSY;
>>> + goto err_out;
>>> + }
>>> + }
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + }
>>
>>
>> Just a notice. Recently, Tejun changed failure of pre_destory() to show WARNING.
>> Then, I'd like to move the usage to the root cgroup if use_hierarchy=0.
>> Will it work for you ?
>
> That should work.
>
ok, I'll go ahead in that way.
>
>>
>>> + /*
>>> + * caller should have done css_get
>>> + */
>>
>>
>> Could you explain meaning of this comment ?
>>
>
> inherited from mem_cgroup_move_account. I guess it means css cannot go
> away at this point. We have done a css_get on the child. For a generic
> move_account function may be the comment is needed. I guess in our case
> the comment is redundant ?
>
Ah, IIUC, this code is hugetlb version of mem_cgroup_move_parent().
At move_parent(), we don't need to take care of css counting because we're
moving from an exisiting cgroup to an cgroup which cannot be destroyed.
(move_account() is function to move account between arbitrary cgroup.)
So, yes, please remove comment.
Thanks,
-Kame
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, mgorman@suse.de, dhillf@gmail.com,
aarcange@redhat.com, mhocko@suse.cz, akpm@linux-foundation.org,
hannes@cmpxchg.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [PATCH -V5 12/14] memcg: move HugeTLB resource count to parent cgroup on memcg removal
Date: Tue, 10 Apr 2012 15:55:33 +0900 [thread overview]
Message-ID: <4F83D965.4040506@jp.fujitsu.com> (raw)
In-Reply-To: <87ty0tcjhx.fsf@skywalker.in.ibm.com>
(2012/04/09 19:00), Aneesh Kumar K.V wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
>
>> (2012/04/07 3:50), Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> This add support for memcg removal with HugeTLB resource usage.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>>
>> Hmm
>>
>>
>
> ....
> ...
>
>>> + csize = PAGE_SIZE << compound_order(page);
>>> + /*
>>> + * uncharge from child and charge the parent. If we have
>>> + * use_hierarchy set, we can never fail here. In-order to make
>>> + * sure we don't get -ENOMEM on parent charge, we first uncharge
>>> + * the child and then charge the parent.
>>> + */
>>> + if (parent->use_hierarchy) {
>>
>>
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + if (!mem_cgroup_is_root(parent))
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>
>>
>> Ah, why is !mem_cgroup_is_root() checked ? no res_counter update for
>> root cgroup ?
>
> My mistake. Earlier version of the patch series didn't charge/uncharge the root
> cgroup during different operations. Later as per your review I updated
> the charge/uncharge path to charge root cgroup. I missed to update this code.
>
>>
>> I think it's better to have res_counter_move_parent()...to do ops in atomic.
>> (I'll post a patch for that for my purpose). OR, just ignore res->usage if
>> parent->use_hierarchy == 1.
>>
>> uncharge->charge will have a race.
>
>
>
> How about the below
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7b6e79a..5b4bc98 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3351,24 +3351,24 @@ int mem_cgroup_move_hugetlb_parent(int idx, struct cgroup *cgroup,
>
> csize = PAGE_SIZE << compound_order(page);
> /*
> - * uncharge from child and charge the parent. If we have
> - * use_hierarchy set, we can never fail here. In-order to make
> - * sure we don't get -ENOMEM on parent charge, we first uncharge
> - * the child and then charge the parent.
> + * If we have use_hierarchy set we can never fail here. So instead of
> + * using res_counter_uncharge use the open-coded variant which just
> + * uncharge the child res_counter. The parent will retain the charge.
> */
> if (parent->use_hierarchy) {
> - res_counter_uncharge(&memcg->hugepage[idx], csize);
> - if (!mem_cgroup_is_root(parent))
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> + unsigned long flags;
> + struct res_counter *counter;
> +
> + counter = &memcg->hugepage[idx];
> + spin_lock_irqsave(&counter->lock, flags);
> + res_counter_uncharge_locked(counter, csize);
Hm, uncharge_locked is not propagated to parent, I see.
Ok, it seems to work...but please add enough comment here. Or define
res_counter_move_parent().
> + spin_unlock_irqrestore(&counter->lock, flags);
> } else {
> - if (!mem_cgroup_is_root(parent)) {
> - ret = res_counter_charge(&parent->hugepage[idx],
> - csize, &fail_res);
> - if (ret) {
> - ret = -EBUSY;
> - goto err_out;
> - }
> + ret = res_counter_charge(&parent->hugepage[idx],
> + csize, &fail_res);
> + if (ret) {
> + ret = -EBUSY;
> + goto err_out;
> }
> res_counter_uncharge(&memcg->hugepage[idx], csize);
> }
>
>
>>
>>> + } else {
>>> + if (!mem_cgroup_is_root(parent)) {
>>> + ret = res_counter_charge(&parent->hugepage[idx],
>>> + csize, &fail_res);
>>> + if (ret) {
>>> + ret = -EBUSY;
>>> + goto err_out;
>>> + }
>>> + }
>>> + res_counter_uncharge(&memcg->hugepage[idx], csize);
>>> + }
>>
>>
>> Just a notice. Recently, Tejun changed failure of pre_destory() to show WARNING.
>> Then, I'd like to move the usage to the root cgroup if use_hierarchy=0.
>> Will it work for you ?
>
> That should work.
>
ok, I'll go ahead in that way.
>
>>
>>> + /*
>>> + * caller should have done css_get
>>> + */
>>
>>
>> Could you explain meaning of this comment ?
>>
>
> inherited from mem_cgroup_move_account. I guess it means css cannot go
> away at this point. We have done a css_get on the child. For a generic
> move_account function may be the comment is needed. I guess in our case
> the comment is redundant ?
>
Ah, IIUC, this code is hugetlb version of mem_cgroup_move_parent().
At move_parent(), we don't need to take care of css counting because we're
moving from an exisiting cgroup to an cgroup which cannot be destroyed.
(move_account() is function to move account between arbitrary cgroup.)
So, yes, please remove comment.
Thanks,
-Kame
next prev parent reply other threads:[~2012-04-10 6:55 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-06 18:50 [PATCH -V5 00/14] memcg: Add memcg extension to control HugeTLB allocation Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 01/14] hugetlb: rename max_hstate to hugetlb_max_hstate Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 02/14] hugetlbfs: don't use ERR_PTR with VM_FAULT* values Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 03/14] hugetlbfs: Add an inline helper for finding hstate index Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 04/14] hugetlb: Use mmu_gather instead of a temporary linked list for accumulating pages Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-09 5:36 ` KAMEZAWA Hiroyuki
2012-04-09 5:36 ` KAMEZAWA Hiroyuki
2012-04-06 18:50 ` [PATCH -V5 05/14] hugetlb: Avoid taking i_mmap_mutex in unmap_single_vma for hugetlb Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 06/14] hugetlb: Simplify migrate_huge_page Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
[not found] ` <1333738260-1329-7-git-send-email-aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2012-04-09 5:47 ` KAMEZAWA Hiroyuki
2012-04-09 5:47 ` KAMEZAWA Hiroyuki
2012-04-09 5:47 ` KAMEZAWA Hiroyuki
2012-04-09 8:36 ` Aneesh Kumar K.V
2012-04-09 8:36 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 07/14] memcg: Add HugeTLB extension Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
[not found] ` <1333738260-1329-8-git-send-email-aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2012-04-09 6:04 ` KAMEZAWA Hiroyuki
2012-04-09 6:04 ` KAMEZAWA Hiroyuki
2012-04-09 6:04 ` KAMEZAWA Hiroyuki
[not found] ` <4F827BF9.2090205-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-09 8:43 ` Aneesh Kumar K.V
2012-04-09 8:43 ` Aneesh Kumar K.V
2012-04-09 8:43 ` Aneesh Kumar K.V
[not found] ` <87zkalcn26.fsf-6yE53ggjAfyqSkle7U1LjlaTQe2KTcn/@public.gmane.org>
2012-04-09 9:00 ` KAMEZAWA Hiroyuki
2012-04-09 9:00 ` KAMEZAWA Hiroyuki
2012-04-09 9:00 ` KAMEZAWA Hiroyuki
2012-04-06 18:50 ` [PATCH -V5 08/14] hugetlb: add charge/uncharge calls for HugeTLB alloc/free Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 09/14] memcg: track resource index in cftype private Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-09 5:56 ` KAMEZAWA Hiroyuki
2012-04-09 5:56 ` KAMEZAWA Hiroyuki
2012-04-06 18:50 ` [PATCH -V5 10/14] hugetlbfs: Add memcg control files for hugetlbfs Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-09 6:00 ` KAMEZAWA Hiroyuki
2012-04-09 6:00 ` KAMEZAWA Hiroyuki
[not found] ` <4F827AF8.9070204-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-09 8:46 ` Aneesh Kumar K.V
2012-04-09 8:46 ` Aneesh Kumar K.V
2012-04-09 8:46 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 11/14] hugetlbfs: Add a list for tracking in-use HugeTLB pages Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:50 ` [PATCH -V5 12/14] memcg: move HugeTLB resource count to parent cgroup on memcg removal Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
[not found] ` <1333738260-1329-13-git-send-email-aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2012-04-09 6:16 ` KAMEZAWA Hiroyuki
2012-04-09 6:16 ` KAMEZAWA Hiroyuki
2012-04-09 6:16 ` KAMEZAWA Hiroyuki
2012-04-09 10:00 ` Aneesh Kumar K.V
2012-04-09 10:00 ` Aneesh Kumar K.V
[not found] ` <87ty0tcjhx.fsf-6yE53ggjAfyqSkle7U1LjlaTQe2KTcn/@public.gmane.org>
2012-04-10 6:55 ` KAMEZAWA Hiroyuki [this message]
2012-04-10 6:55 ` KAMEZAWA Hiroyuki
2012-04-10 6:55 ` KAMEZAWA Hiroyuki
2012-04-06 18:50 ` [PATCH -V5 13/14] hugetlb: migrate memcg info from oldpage to new page during migration Aneesh Kumar K.V
2012-04-06 18:50 ` Aneesh Kumar K.V
2012-04-06 18:51 ` [PATCH -V5 14/14] memcg: Add memory controller documentation for hugetlb management Aneesh Kumar K.V
2012-04-06 18:51 ` 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=4F83D965.4040506@jp.fujitsu.com \
--to=kamezawa.hiroyu-+cum20s59erqfuhtdcdx3a@public.gmane.org \
--cc=aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dhillf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mgorman-l3A5Bk7waGM@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
/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.