* [PATCH 0/2] Support hugetlb charge moving at task migration
@ 2021-09-29 10:19 Baolin Wang
2021-09-29 10:19 ` [PATCH 1/2] hugetlb_cgroup: Add interfaces to move hugetlb charge " Baolin Wang
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Baolin Wang @ 2021-09-29 10:19 UTC (permalink / raw)
To: akpm; +Cc: baolin.wang, linux-mm, linux-kernel
Hi,
Now in the hugetlb cgroup, charges associated with a task aren't moved
to the new hugetlb cgroup at task migration, which is odd for hugetlb
cgroup usage. This patch set adds hugetlb cgroup charge moving when
migrate tasks among cgroups, which are based on the memcg charge moving.
Please help to review. Thanks.
Baolin Wang (2):
hugetlb_cgroup: Add interfaces to move hugetlb charge at task
migration
hugetlb_cgroup: Add post_attach interface for tasks migration
mm/hugetlb_cgroup.c | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 230 insertions(+)
--
1.8.3.1
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 1/2] hugetlb_cgroup: Add interfaces to move hugetlb charge at task migration
2021-09-29 10:19 [PATCH 0/2] Support hugetlb charge moving at task migration Baolin Wang
@ 2021-09-29 10:19 ` Baolin Wang
2021-09-29 10:19 ` [PATCH 2/2] hugetlb_cgroup: Add post_attach interface for tasks migration Baolin Wang
2021-09-30 10:46 ` [PATCH 0/2] Support hugetlb charge moving at task migration Michal Hocko
2 siblings, 0 replies; 9+ messages in thread
From: Baolin Wang @ 2021-09-29 10:19 UTC (permalink / raw)
To: akpm; +Cc: baolin.wang, linux-mm, linux-kernel
Now in the hugetlb cgroup, charges associated with a task aren't moved
to the new hugetlb cgroup at task migration, which is not reasonable.
Thus this patch set adds some interfaces for charging to the new hugetlb
cgroup and uncharging from the old hugetlb cgroup at task migration.
This patch adds can_attach() and cancel_attach() to check if we can
charge to the new hugetlb cgroup.
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
mm/hugetlb_cgroup.c | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 162 insertions(+)
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 5383023..2568d0c 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -19,6 +19,7 @@
#include <linux/cgroup.h>
#include <linux/page_counter.h>
+#include <linux/pagewalk.h>
#include <linux/slab.h>
#include <linux/hugetlb.h>
#include <linux/hugetlb_cgroup.h>
@@ -32,6 +33,14 @@
static struct hugetlb_cgroup *root_h_cgroup __read_mostly;
+static struct hugetlb_move_charge {
+ struct mm_struct *mm;
+ struct hugetlb_cgroup *from;
+ struct hugetlb_cgroup *to;
+ unsigned long precharge[HUGE_MAX_HSTATE];
+ unsigned long moved_charge[HUGE_MAX_HSTATE];
+} hmc;
+
static inline struct page_counter *
__hugetlb_cgroup_counter_from_cgroup(struct hugetlb_cgroup *h_cg, int idx,
bool rsvd)
@@ -151,6 +160,157 @@ static void hugetlb_cgroup_css_free(struct cgroup_subsys_state *css)
kfree(h_cgroup);
}
+static int hugetlb_cgroup_precharge_pte_range(pte_t *pte, unsigned long hmask,
+ unsigned long addr,
+ unsigned long end,
+ struct mm_walk *walk)
+{
+ struct page *page;
+ spinlock_t *ptl;
+ pte_t entry;
+ struct hstate *h = hstate_vma(walk->vma);
+
+ ptl = huge_pte_lock(h, walk->mm, pte);
+ entry = huge_ptep_get(pte);
+ /* TODO: only handle present hugetlb pages now. */
+ if (!pte_present(entry)) {
+ spin_unlock(ptl);
+ return 0;
+ }
+
+ page = pte_page(entry);
+ spin_unlock(ptl);
+
+ spin_lock_irq(&hugetlb_lock);
+ if (hugetlb_cgroup_from_page(page) == hmc.from) {
+ int idx = hstate_index(h);
+
+ hmc.precharge[idx]++;
+ }
+ spin_unlock_irq(&hugetlb_lock);
+
+ cond_resched();
+ return 0;
+}
+
+static const struct mm_walk_ops hugetlb_precharge_walk_ops = {
+ .hugetlb_entry = hugetlb_cgroup_precharge_pte_range,
+};
+
+static int hugetlb_cgroup_precharge(struct mm_struct *mm)
+{
+ struct page_counter *counter;
+ unsigned long precharge;
+ int idx;
+
+ mmap_read_lock(mm);
+ walk_page_range(mm, 0, mm->highest_vm_end, &hugetlb_precharge_walk_ops, NULL);
+ mmap_read_unlock(mm);
+
+ for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) {
+ if (!hmc.precharge[idx])
+ continue;
+
+ precharge = hmc.precharge[idx];
+ hmc.precharge[idx] = 0;
+
+ if (!page_counter_try_charge(
+ __hugetlb_cgroup_counter_from_cgroup(hmc.to, idx, false),
+ precharge * pages_per_huge_page(&hstates[idx]), &counter))
+ return -ENOMEM;
+
+ hmc.precharge[idx] = precharge;
+ }
+
+ return 0;
+}
+
+static void hugetlb_cgroup_clear(void)
+{
+ struct mm_struct *mm = hmc.mm;
+ struct hugetlb_cgroup *to = hmc.to;
+ int idx;
+
+ /* we must uncharge all the leftover precharges from hmc.to */
+ for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) {
+ if (!hmc.precharge[idx])
+ continue;
+
+ page_counter_uncharge(
+ __hugetlb_cgroup_counter_from_cgroup(to, idx, false),
+ hmc.precharge[idx] * pages_per_huge_page(&hstates[idx]));
+ hmc.precharge[idx] = 0;
+ }
+
+ hmc.from = NULL;
+ hmc.to = NULL;
+ hmc.mm = NULL;
+
+ mmput(mm);
+}
+
+static int hugetlb_cgroup_can_attach(struct cgroup_taskset *tset)
+{
+ struct cgroup_subsys_state *css;
+ struct task_struct *leader, *p;
+ struct hugetlb_cgroup *h_cgroup, *from_hcg;
+ struct mm_struct *mm;
+ int ret = 0, idx;
+
+ if (hugetlb_cgroup_disabled())
+ return 0;
+
+ /*
+ * Multi-process migrations only happen on the default hierarchy
+ * where charge immigration is not used. Perform charge
+ * immigration if @tset contains a leader and whine if there are
+ * multiple.
+ */
+ p = NULL;
+ cgroup_taskset_for_each_leader(leader, css, tset) {
+ WARN_ON_ONCE(p);
+ p = leader;
+ h_cgroup = hugetlb_cgroup_from_css(css);
+ }
+ if (!p)
+ return 0;
+
+ from_hcg = hugetlb_cgroup_from_task(p);
+ VM_BUG_ON(from_hcg == h_cgroup);
+
+ mm = get_task_mm(p);
+ if (!mm)
+ return 0;
+
+ VM_BUG_ON(hmc.from);
+ VM_BUG_ON(hmc.to);
+ VM_BUG_ON(hmc.mm);
+
+ for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) {
+ VM_BUG_ON(hmc.precharge[idx]);
+ VM_BUG_ON(hmc.moved_charge[idx]);
+ }
+
+ hmc.mm = mm;
+ hmc.from = from_hcg;
+ hmc.to = h_cgroup;
+
+ ret = hugetlb_cgroup_precharge(mm);
+ if (ret)
+ hugetlb_cgroup_clear();
+
+ return ret;
+}
+
+static void hugetlb_cgroup_cancel_attach(struct cgroup_taskset *tset)
+{
+ if (hugetlb_cgroup_disabled())
+ return;
+
+ if (hmc.to)
+ hugetlb_cgroup_clear();
+}
+
/*
* Should be called with hugetlb_lock held.
* Since we are holding hugetlb_lock, pages cannot get moved from
@@ -806,6 +966,8 @@ struct cgroup_subsys hugetlb_cgrp_subsys = {
.css_alloc = hugetlb_cgroup_css_alloc,
.css_offline = hugetlb_cgroup_css_offline,
.css_free = hugetlb_cgroup_css_free,
+ .can_attach = hugetlb_cgroup_can_attach,
+ .cancel_attach = hugetlb_cgroup_cancel_attach,
.dfl_cftypes = hugetlb_files,
.legacy_cftypes = hugetlb_files,
};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/2] hugetlb_cgroup: Add post_attach interface for tasks migration
2021-09-29 10:19 [PATCH 0/2] Support hugetlb charge moving at task migration Baolin Wang
2021-09-29 10:19 ` [PATCH 1/2] hugetlb_cgroup: Add interfaces to move hugetlb charge " Baolin Wang
@ 2021-09-29 10:19 ` Baolin Wang
2021-09-30 10:46 ` [PATCH 0/2] Support hugetlb charge moving at task migration Michal Hocko
2 siblings, 0 replies; 9+ messages in thread
From: Baolin Wang @ 2021-09-29 10:19 UTC (permalink / raw)
To: akpm; +Cc: baolin.wang, linux-mm, linux-kernel
Add post_attach interface to change the page's hugetlb cgroup
and uncharge the old hugetlb cgroup when tasks migration finished.
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
mm/hugetlb_cgroup.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 2568d0c..bd53d04 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -229,6 +229,7 @@ static void hugetlb_cgroup_clear(void)
{
struct mm_struct *mm = hmc.mm;
struct hugetlb_cgroup *to = hmc.to;
+ struct hugetlb_cgroup *from = hmc.from;
int idx;
/* we must uncharge all the leftover precharges from hmc.to */
@@ -242,6 +243,17 @@ static void hugetlb_cgroup_clear(void)
hmc.precharge[idx] = 0;
}
+ for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) {
+ if (!hmc.moved_charge[idx])
+ continue;
+
+ page_counter_uncharge(
+ __hugetlb_cgroup_counter_from_cgroup(from, idx, false),
+ hmc.moved_charge[idx] * pages_per_huge_page(&hstates[idx]));
+
+ hmc.moved_charge[idx] = 0;
+ }
+
hmc.from = NULL;
hmc.to = NULL;
hmc.mm = NULL;
@@ -311,6 +323,61 @@ static void hugetlb_cgroup_cancel_attach(struct cgroup_taskset *tset)
hugetlb_cgroup_clear();
}
+static int hugetlb_cgroup_move_charge_pte_range(pte_t *pte, unsigned long hmask,
+ unsigned long addr,
+ unsigned long end,
+ struct mm_walk *walk)
+{
+ struct page *page;
+ spinlock_t *ptl;
+ pte_t entry;
+ struct hstate *h = hstate_vma(walk->vma);
+
+ ptl = huge_pte_lock(h, walk->mm, pte);
+ entry = huge_ptep_get(pte);
+ /* TODO: only handle present hugetlb pages now. */
+ if (!pte_present(entry)) {
+ spin_unlock(ptl);
+ return 0;
+ }
+
+ page = pte_page(entry);
+ spin_unlock(ptl);
+
+ spin_lock_irq(&hugetlb_lock);
+ if (hugetlb_cgroup_from_page(page) == hmc.from) {
+ int idx = hstate_index(h);
+
+ set_hugetlb_cgroup(page, hmc.to);
+ hmc.precharge[idx]--;
+ hmc.moved_charge[idx]++;
+ }
+ spin_unlock_irq(&hugetlb_lock);
+
+ cond_resched();
+ return 0;
+}
+
+static const struct mm_walk_ops hugetlb_charge_walk_ops = {
+ .hugetlb_entry = hugetlb_cgroup_move_charge_pte_range,
+};
+
+static void hugetlb_cgroup_move_task(void)
+{
+ if (hugetlb_cgroup_disabled())
+ return;
+
+ if (!hmc.to)
+ return;
+
+ mmap_read_lock(hmc.mm);
+ walk_page_range(hmc.mm, 0, hmc.mm->highest_vm_end,
+ &hugetlb_charge_walk_ops, NULL);
+ mmap_read_unlock(hmc.mm);
+
+ hugetlb_cgroup_clear();
+}
+
/*
* Should be called with hugetlb_lock held.
* Since we are holding hugetlb_lock, pages cannot get moved from
@@ -968,6 +1035,7 @@ struct cgroup_subsys hugetlb_cgrp_subsys = {
.css_free = hugetlb_cgroup_css_free,
.can_attach = hugetlb_cgroup_can_attach,
.cancel_attach = hugetlb_cgroup_cancel_attach,
+ .post_attach = hugetlb_cgroup_move_task,
.dfl_cftypes = hugetlb_files,
.legacy_cftypes = hugetlb_files,
};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-09-29 10:19 [PATCH 0/2] Support hugetlb charge moving at task migration Baolin Wang
2021-09-29 10:19 ` [PATCH 1/2] hugetlb_cgroup: Add interfaces to move hugetlb charge " Baolin Wang
2021-09-29 10:19 ` [PATCH 2/2] hugetlb_cgroup: Add post_attach interface for tasks migration Baolin Wang
@ 2021-09-30 10:46 ` Michal Hocko
2021-10-07 15:39 ` Baolin Wang
2 siblings, 1 reply; 9+ messages in thread
From: Michal Hocko @ 2021-09-30 10:46 UTC (permalink / raw)
To: Baolin Wang; +Cc: akpm, linux-mm, linux-kernel
On Wed 29-09-21 18:19:26, Baolin Wang wrote:
> Hi,
>
> Now in the hugetlb cgroup, charges associated with a task aren't moved
> to the new hugetlb cgroup at task migration, which is odd for hugetlb
> cgroup usage.
Could you elaborate some more about the usecase and/or problems you see
with the existing semantic?
> This patch set adds hugetlb cgroup charge moving when
> migrate tasks among cgroups, which are based on the memcg charge moving.
Memcg charge moving has shown some problems over time and hence this is
not part of cgroup v2 interface anymore. Even for cgroup v1 this has
been an opt-in. I do not see anything like that in this patch series.
Why should all existing workloads follow a different semantic during
task migration now?
> Please help to review. Thanks.
>
> Baolin Wang (2):
> hugetlb_cgroup: Add interfaces to move hugetlb charge at task
> migration
> hugetlb_cgroup: Add post_attach interface for tasks migration
>
> mm/hugetlb_cgroup.c | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 230 insertions(+)
>
> --
> 1.8.3.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-09-30 10:46 ` [PATCH 0/2] Support hugetlb charge moving at task migration Michal Hocko
@ 2021-10-07 15:39 ` Baolin Wang
2021-10-08 7:12 ` Michal Hocko
0 siblings, 1 reply; 9+ messages in thread
From: Baolin Wang @ 2021-10-07 15:39 UTC (permalink / raw)
To: Michal Hocko; +Cc: akpm, linux-mm, linux-kernel
Hi Michal,
(Sorry for late reply due to my holidays)
On 2021/9/30 18:46, Michal Hocko wrote:
> On Wed 29-09-21 18:19:26, Baolin Wang wrote:
>> Hi,
>>
>> Now in the hugetlb cgroup, charges associated with a task aren't moved
>> to the new hugetlb cgroup at task migration, which is odd for hugetlb
>> cgroup usage.
>
> Could you elaborate some more about the usecase and/or problems you see
> with the existing semantic?
The problems is that, it did not check if the tasks can move to the new
hugetlb cgroup if the new hugetlb cgroup has a limitation, and the
hugetlb cgroup usage is incorrect when moving tasks among hugetlb cgroups.
>
>> This patch set adds hugetlb cgroup charge moving when
>> migrate tasks among cgroups, which are based on the memcg charge moving.
>
> Memcg charge moving has shown some problems over time and hence this is
> not part of cgroup v2 interface anymore. Even for cgroup v1 this has
Sorry, I missed this part, could you elaborate on the issues? I can have
a close look about the problems of memcg charge moving.
> been an opt-in. I do not see anything like that in this patch series.
> Why should all existing workloads follow a different semantic during
> task migration now?
But I think it is reasonable for some cases moving the old charging to
the new cgroup when task migration. Maybe I can add a new hugetlb cgroup
file to control if need this or not?
Thanks for your comments.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-10-07 15:39 ` Baolin Wang
@ 2021-10-08 7:12 ` Michal Hocko
2021-10-08 9:17 ` Baolin Wang
0 siblings, 1 reply; 9+ messages in thread
From: Michal Hocko @ 2021-10-08 7:12 UTC (permalink / raw)
To: Baolin Wang; +Cc: akpm, linux-mm, linux-kernel
On Thu 07-10-21 23:39:15, Baolin Wang wrote:
> Hi Michal,
>
> (Sorry for late reply due to my holidays)
> On 2021/9/30 18:46, Michal Hocko wrote:
> > On Wed 29-09-21 18:19:26, Baolin Wang wrote:
> > > Hi,
> > >
> > > Now in the hugetlb cgroup, charges associated with a task aren't moved
> > > to the new hugetlb cgroup at task migration, which is odd for hugetlb
> > > cgroup usage.
> >
> > Could you elaborate some more about the usecase and/or problems you see
> > with the existing semantic?
>
> The problems is that, it did not check if the tasks can move to the new
> hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb
> cgroup usage is incorrect when moving tasks among hugetlb cgroups.
Could you be more specific please? What do you mean by cgroup usage is
incorrect? Ideally could you describe your usecase?
> > > This patch set adds hugetlb cgroup charge moving when
> > > migrate tasks among cgroups, which are based on the memcg charge moving.
> >
> > Memcg charge moving has shown some problems over time and hence this is
> > not part of cgroup v2 interface anymore. Even for cgroup v1 this has
>
> Sorry, I missed this part, could you elaborate on the issues? I can have a
> close look about the problems of memcg charge moving.
The operation is quite expensive. Synchronization with charging is not
trivial. I do not have the full list handy but you can search the
mm mailing list archives for more information.
> > been an opt-in. I do not see anything like that in this patch series.
> > Why should all existing workloads follow a different semantic during
> > task migration now?
>
> But I think it is reasonable for some cases moving the old charging to the
> new cgroup when task migration. Maybe I can add a new hugetlb cgroup file to
> control if need this or not?
It would be good to describe those use cases and why they really need
this. Because as things stand now, the charge migration is not supported
in cgroup v2 for memory cgroup controller and there are no plans to add
the support so it would be quite unexpected that hugetlb controller
would behave differently. And cgroup v1 is considered legacy and new
features are ususally not added as there is a hope to move users to v2.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-10-08 7:12 ` Michal Hocko
@ 2021-10-08 9:17 ` Baolin Wang
2021-10-08 11:55 ` Michal Hocko
0 siblings, 1 reply; 9+ messages in thread
From: Baolin Wang @ 2021-10-08 9:17 UTC (permalink / raw)
To: Michal Hocko; +Cc: akpm, linux-mm, linux-kernel
On 2021/10/8 15:12, Michal Hocko wrote:
> On Thu 07-10-21 23:39:15, Baolin Wang wrote:
>> Hi Michal,
>>
>> (Sorry for late reply due to my holidays)
>> On 2021/9/30 18:46, Michal Hocko wrote:
>>> On Wed 29-09-21 18:19:26, Baolin Wang wrote:
>>>> Hi,
>>>>
>>>> Now in the hugetlb cgroup, charges associated with a task aren't moved
>>>> to the new hugetlb cgroup at task migration, which is odd for hugetlb
>>>> cgroup usage.
>>>
>>> Could you elaborate some more about the usecase and/or problems you see
>>> with the existing semantic?
>>
>> The problems is that, it did not check if the tasks can move to the new
>> hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb
>> cgroup usage is incorrect when moving tasks among hugetlb cgroups.
>
> Could you be more specific please? What do you mean by cgroup usage is
> incorrect? Ideally could you describe your usecase?
Sorry for confusing, what I mean is, when tasks from one hugetlb cgroup
are migrated to a new hugetlb cgroup, the new hugetlb cgroup's hugetlb
page usage is not increased accordingly. The issue I found is just from
my testing for the hugetlb cgroup, and I think this is not resonable if
we've already set a hugetlb limitation for a cgroup, but we always
ignore it when tasks migration among hugetlb cgroups.
>>>> This patch set adds hugetlb cgroup charge moving when
>>>> migrate tasks among cgroups, which are based on the memcg charge moving.
>>>
>>> Memcg charge moving has shown some problems over time and hence this is
>>> not part of cgroup v2 interface anymore. Even for cgroup v1 this has
>>
>> Sorry, I missed this part, could you elaborate on the issues? I can have a
>> close look about the problems of memcg charge moving.
>
> The operation is quite expensive. Synchronization with charging is not
> trivial. I do not have the full list handy but you can search the
> mm mailing list archives for more information.
Sure, thanks.
>
>>> been an opt-in. I do not see anything like that in this patch series.
>>> Why should all existing workloads follow a different semantic during
>>> task migration now?
>>
>> But I think it is reasonable for some cases moving the old charging to the
>> new cgroup when task migration. Maybe I can add a new hugetlb cgroup file to
>> control if need this or not?
>
> It would be good to describe those use cases and why they really need
> this. Because as things stand now, the charge migration is not supported
> in cgroup v2 for memory cgroup controller and there are no plans to add
> the support so it would be quite unexpected that hugetlb controller
> would behave differently. And cgroup v1 is considered legacy and new
> features are ususally not added as there is a hope to move users to v2.
OK, understood. Seems you have a strong opinion that it is unnecessary
to introduce this feature for cgroup v1 now, then I will drop this patch
set. Thanks for your input.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-10-08 9:17 ` Baolin Wang
@ 2021-10-08 11:55 ` Michal Hocko
2021-10-09 14:24 ` Baolin Wang
0 siblings, 1 reply; 9+ messages in thread
From: Michal Hocko @ 2021-10-08 11:55 UTC (permalink / raw)
To: Baolin Wang; +Cc: akpm, linux-mm, linux-kernel
On Fri 08-10-21 17:17:12, Baolin Wang wrote:
>
>
> On 2021/10/8 15:12, Michal Hocko wrote:
> > On Thu 07-10-21 23:39:15, Baolin Wang wrote:
> > > Hi Michal,
> > >
> > > (Sorry for late reply due to my holidays)
> > > On 2021/9/30 18:46, Michal Hocko wrote:
> > > > On Wed 29-09-21 18:19:26, Baolin Wang wrote:
> > > > > Hi,
> > > > >
> > > > > Now in the hugetlb cgroup, charges associated with a task aren't moved
> > > > > to the new hugetlb cgroup at task migration, which is odd for hugetlb
> > > > > cgroup usage.
> > > >
> > > > Could you elaborate some more about the usecase and/or problems you see
> > > > with the existing semantic?
> > >
> > > The problems is that, it did not check if the tasks can move to the new
> > > hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb
> > > cgroup usage is incorrect when moving tasks among hugetlb cgroups.
> >
> > Could you be more specific please? What do you mean by cgroup usage is
> > incorrect? Ideally could you describe your usecase?
>
> Sorry for confusing, what I mean is, when tasks from one hugetlb cgroup are
> migrated to a new hugetlb cgroup, the new hugetlb cgroup's hugetlb page
> usage is not increased accordingly.
Which is a perferctly reasonable behavior as the memory has been
consumed from the original cgroup and it will be freed there as well.
Migrating to a new cgroup doesn't imply all the resources to be migrated
as well.
> The issue I found is just from my
> testing for the hugetlb cgroup, and I think this is not resonable if we've
> already set a hugetlb limitation for a cgroup, but we always ignore it when
> tasks migration among hugetlb cgroups.
I would like to learn more about why you consider this unreasonable.
This will likely depend on the reason why you want/need to migrate task.
If you want to move a task to completely new resource domain (read a
completely different cgroup subtree) then I can imagine you want to
leave all the resources but this will have problems with other resource
controllers - e.g. memory cgroup v2 which doesn't allow charge migration
either.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/2] Support hugetlb charge moving at task migration
2021-10-08 11:55 ` Michal Hocko
@ 2021-10-09 14:24 ` Baolin Wang
0 siblings, 0 replies; 9+ messages in thread
From: Baolin Wang @ 2021-10-09 14:24 UTC (permalink / raw)
To: Michal Hocko; +Cc: akpm, linux-mm, linux-kernel
On 2021/10/8 19:55, Michal Hocko wrote:
> On Fri 08-10-21 17:17:12, Baolin Wang wrote:
>>
>>
>> On 2021/10/8 15:12, Michal Hocko wrote:
>>> On Thu 07-10-21 23:39:15, Baolin Wang wrote:
>>>> Hi Michal,
>>>>
>>>> (Sorry for late reply due to my holidays)
>>>> On 2021/9/30 18:46, Michal Hocko wrote:
>>>>> On Wed 29-09-21 18:19:26, Baolin Wang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Now in the hugetlb cgroup, charges associated with a task aren't moved
>>>>>> to the new hugetlb cgroup at task migration, which is odd for hugetlb
>>>>>> cgroup usage.
>>>>>
>>>>> Could you elaborate some more about the usecase and/or problems you see
>>>>> with the existing semantic?
>>>>
>>>> The problems is that, it did not check if the tasks can move to the new
>>>> hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb
>>>> cgroup usage is incorrect when moving tasks among hugetlb cgroups.
>>>
>>> Could you be more specific please? What do you mean by cgroup usage is
>>> incorrect? Ideally could you describe your usecase?
>>
>> Sorry for confusing, what I mean is, when tasks from one hugetlb cgroup are
>> migrated to a new hugetlb cgroup, the new hugetlb cgroup's hugetlb page
>> usage is not increased accordingly.
>
> Which is a perferctly reasonable behavior as the memory has been
> consumed from the original cgroup and it will be freed there as well.
> Migrating to a new cgroup doesn't imply all the resources to be migrated
> as well.
OK.
>> The issue I found is just from my
>> testing for the hugetlb cgroup, and I think this is not resonable if we've
>> already set a hugetlb limitation for a cgroup, but we always ignore it when
>> tasks migration among hugetlb cgroups.
>
> I would like to learn more about why you consider this unreasonable.
> This will likely depend on the reason why you want/need to migrate task.
> If you want to move a task to completely new resource domain (read a
Yes.
> completely different cgroup subtree) then I can imagine you want to
> leave all the resources but this will have problems with other resource
> controllers - e.g. memory cgroup v2 which doesn't allow charge migration
> either.
OK. I see. Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-10-09 14:24 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-29 10:19 [PATCH 0/2] Support hugetlb charge moving at task migration Baolin Wang
2021-09-29 10:19 ` [PATCH 1/2] hugetlb_cgroup: Add interfaces to move hugetlb charge " Baolin Wang
2021-09-29 10:19 ` [PATCH 2/2] hugetlb_cgroup: Add post_attach interface for tasks migration Baolin Wang
2021-09-30 10:46 ` [PATCH 0/2] Support hugetlb charge moving at task migration Michal Hocko
2021-10-07 15:39 ` Baolin Wang
2021-10-08 7:12 ` Michal Hocko
2021-10-08 9:17 ` Baolin Wang
2021-10-08 11:55 ` Michal Hocko
2021-10-09 14:24 ` Baolin Wang
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).