memcg Can't context between v1 and v2 because css->refcnt not released

memcg Can't context between v1 and v2 because css->refcnt not released

[喻望]

Hello Johannes ,Michal,and Tejun:

  i using memcg v1,  but some reason  i want to context to  memcg v2,
but i can't, here is my step:
#cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
 memory 5 1 1
#cd /sys/fs/cgroup/memory
#mkdir a
#echo 0 > a/cgroup.procs
#sleep 1
#echo 0 > cgroup.procs
#cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
 memory 5 2 1  
the num_cgroups not go to "1"
so it will lead to can't context to memcg 2
#cd ..
#umount memory
umount: /sys/fs/cgroup/memory: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

  and i have tracked  the root cause, i found that "b2052564e66d mm:
memcontrol: continue cache reclaim from offlined groups"from Johannes
Weiner, remove mem_cgroup_reparent_charges when mem_cgroup_css_offline, so
the css->refcount  not go to "0", so the css_release not call when rmdir
cgroup, and nr_cgroups not released.
  so i want to ask does it reasonable can't context between v1 and v2


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

memcg Can't context between v1 and v2 because css->refcnt not released

[wang Yu]

Hello Johannes ,Michal,and Tejun:

  i using memcg v1,  but some reason  i want to context to  memcg v2,
but i can't, here is my step:
#cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
 memory 5 1 1
#cd /sys/fs/cgroup/memory
#mkdir a
#echo 0 > a/cgroup.procs
#sleep 1
#echo 0 > cgroup.procs
#cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
 memory 5 2 1
the num_cgroups not go to "1"
so it will lead to can't context to memcg 2
#cd ..
#umount memory
umount: /sys/fs/cgroup/memory: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

  and i have tracked  the root cause, i found that "b2052564e66d mm:
memcontrol: continue cache reclaim from offlined groups"from Johannes
Weiner, remove mem_cgroup_reparent_charges when mem_cgroup_css_offline, so
the css->refcount  not go to "0", so the css_release not call when rmdir
cgroup, and nr_cgroups not released.
  so i want to ask does it reasonable can't context between v1 and v2

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[Michal Hocko]

On Wed 09-08-17 15:06:34, wang Yu wrote:
> Hello Johannes ,Michal,and Tejun:
> 
>   i using memcg v1,  but some reason  i want to context to  memcg v2,
> but i can't, here is my step:
> #cat /proc/cgroups
> #subsys_name hierarchy num_cgroups enabled
>  memory 5 1 1
> #cd /sys/fs/cgroup/memory
> #mkdir a
> #echo 0 > a/cgroup.procs
> #sleep 1
> #echo 0 > cgroup.procs

This doesn't do what you think. It will try to add a non-existant pid 0
to the root cgroup. You need to remove cgroup a. Moreover it is possible
that the `sleep' command will fault some page cache and that will stay
in memcg `a' until there is a memory pressure. cgroup v1 had
force_empty knob which you can use to drain the cgroup before removal.
Then you should be able to umount the v1 cgroup and mount v2.
-- 
Michal Hocko
SUSE Labs

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[wang Yu]

at first ,thanks for your reply.
but i also tested what you said, the problem is also.
force_empty only call try_to_free_pages, not all the pages remove
because mem_cgroup_reparent_charges moved
#cd /sys/fs/cgroup/memory
#mkdir a
#echo 0 > a/cgroup.procs
#sleep 1
#echo 0 > a/cgroup.procs
#echo 1 > a/memory.force_empty
#rmdir a
#cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
memory 2 2 1
the num_cgroups also not released





2017-08-10 15:10 GMT+08:00 Michal Hocko <mhocko@kernel.org>:
> On Wed 09-08-17 15:06:34, wang Yu wrote:
>> Hello Johannes ,Michal,and Tejun:
>>
>>   i using memcg v1,  but some reason  i want to context to  memcg v2,
>> but i can't, here is my step:
>> #cat /proc/cgroups
>> #subsys_name hierarchy num_cgroups enabled
>>  memory 5 1 1
>> #cd /sys/fs/cgroup/memory
>> #mkdir a
>> #echo 0 > a/cgroup.procs
>> #sleep 1
>> #echo 0 > cgroup.procs
>
> This doesn't do what you think. It will try to add a non-existant pid 0
> to the root cgroup. You need to remove cgroup a. Moreover it is possible
> that the `sleep' command will fault some page cache and that will stay
> in memcg `a' until there is a memory pressure. cgroup v1 had
> force_empty knob which you can use to drain the cgroup before removal.
> Then you should be able to umount the v1 cgroup and mount v2.
> --
> Michal Hocko
> SUSE Labs

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[Michal Hocko]

[Please do not top-post]

On Thu 10-08-17 16:10:45, wang Yu wrote:
> at first ,thanks for your reply.
> but i also tested what you said, the problem is also.
> force_empty only call try_to_free_pages, not all the pages remove
> because mem_cgroup_reparent_charges moved

Right. An alternative would be dropping the page cache globaly via
/proc/sys/vm/drop_caches. Not an ideal solution but it should help.
-- 
Michal Hocko
SUSE Labs

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[wang Yu]

2017-08-10 16:19 GMT+08:00 Michal Hocko <mhocko@kernel.org>:
> [Please do not top-post]
>
> On Thu 10-08-17 16:10:45, wang Yu wrote:
>> at first ,thanks for your reply.
>> but i also tested what you said, the problem is also.
>> force_empty only call try_to_free_pages, not all the pages remove
>> because mem_cgroup_reparent_charges moved
>
> Right. An alternative would be dropping the page cache globaly via
> /proc/sys/vm/drop_caches. Not an ideal solution but it should help.
> --
> Michal Hocko
> SUSE Labs

thanks again, but /proc/sys/vm/drop_caches can't solve it
you can try as follow

#cat /proc/cgroups

memory 11 2 1

#mkdir a

#echo 0 > a/cgroup.procs

#sleep 1

#echo 0 > cgroup.procs

#echo 1 > a/memory.force_empty

#echo 3 > /proc/sys/vm/drop_caches

#rmdir  a

#cat /proc/cgroups

memory 11 3 1
the  num_cgroups not decrease

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[wang Yu]

2017-08-10 16:26 GMT+08:00 wang Yu <yuwang668899@gmail.com>:
> 2017-08-10 16:19 GMT+08:00 Michal Hocko <mhocko@kernel.org>:
>> [Please do not top-post]
>>
>> On Thu 10-08-17 16:10:45, wang Yu wrote:
>>> at first ,thanks for your reply.
>>> but i also tested what you said, the problem is also.
>>> force_empty only call try_to_free_pages, not all the pages remove
>>> because mem_cgroup_reparent_charges moved
>>
>> Right. An alternative would be dropping the page cache globaly via
>> /proc/sys/vm/drop_caches. Not an ideal solution but it should help.
>> --
>> Michal Hocko
>> SUSE Labs
>
> thanks again, but /proc/sys/vm/drop_caches can't solve it
> you can try as follow
>
> #cat /proc/cgroups
>
> memory 11 2 1
>
> #mkdir a
>
> #echo 0 > a/cgroup.procs
>
> #sleep 1
>
> #echo 0 > cgroup.procs
>
> #echo 1 > a/memory.force_empty
>
> #echo 3 > /proc/sys/vm/drop_caches
>
> #rmdir  a
>
> #cat /proc/cgroups
>
> memory 11 3 1
> the  num_cgroups not decrease
and i found that, after drop cache

after drop caches, memory.stat  shows not pages belong the group, but
memory.usage_in_bytes not zero, so maybe other pages
has wrong to belong this cgroup

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[Michal Hocko]

[restoring the CC list]

On Thu 10-08-17 17:57:38, wang Yu wrote:
> 2017-08-10 17:28 GMT+08:00 wang Yu <yuwang668899@gmail.com>:
[...]
> > after drop caches, memory.stat  shows not pages belong the group, but
> > memory.usage_in_bytes not zero, so maybe other pages
> > has wrong to belong this group
>
> after drop cache, there maybe have kmem pages ,e.g. slab
> it can't free both drop cache or tasks free,
> so back this problem, without mem_cgroup_reparent_charges,
> cgroup v1 can't umount , and cgroup v2 can't mount

Ohh, right. It is true that there is no explicit control over kmem page
life time. I am afraid this is something non-trivial to address though.
I am not sure swithing between cgroup versions is a strong enough use
case to implement something like that but you can definitely try to do
that.
-- 
Michal Hocko
SUSE Labs

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: memcg Can't context between v1 and v2 because css->refcnt not released

[Johannes Weiner]

On Thu, Aug 10, 2017 at 12:34:06PM +0200, Michal Hocko wrote:
> [restoring the CC list]
> 
> On Thu 10-08-17 17:57:38, wang Yu wrote:
> > 2017-08-10 17:28 GMT+08:00 wang Yu <yuwang668899@gmail.com>:
> [...]
> > > after drop caches, memory.stat  shows not pages belong the group, but
> > > memory.usage_in_bytes not zero, so maybe other pages
> > > has wrong to belong this group
> >
> > after drop cache, there maybe have kmem pages ,e.g. slab
> > it can't free both drop cache or tasks free,
> > so back this problem, without mem_cgroup_reparent_charges,
> > cgroup v1 can't umount , and cgroup v2 can't mount
> 
> Ohh, right. It is true that there is no explicit control over kmem page
> life time. I am afraid this is something non-trivial to address though.
> I am not sure swithing between cgroup versions is a strong enough use
> case to implement something like that but you can definitely try to do
> that.

Pretty much.

The idea was being able to switch after bootup to make interaction
with the init system easier (automatic mounts etc.), not that you can
switch back and forth between using v1 and v2 controllers.

Once the controller has been used and accumulated state, switching
controller versions is no longer supported.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>