On 07/13/2018 03:34 PM, Konstantin Khorenko wrote:
> Do we need it to RK as well for older kernels?
>
Yes.
> --
> Best regards,
>
> Konstantin Khorenko,
> Virtuozzo Linux Kernel Team
>
> On 07/13/2018 02:28 PM, Andrey Ryabinin wrote:
>> Charges to offlined cgroup can happen. E.g. swapped
The commit is pushed to "branch-rh7-3.10.0-862.6.3.vz7.62.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-862.6.3.vz7.62.3
-->
commit cb5488bae3555a8696554010d151b9bfb7934cc1
Author: Pavel Tikhomirov
Date: Fri Jul 13 15:35:32 2018 +0300
ve/mount:
The commit is pushed to "branch-rh7-3.10.0-862.6.3.vz7.62.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-862.6.3.vz7.62.3
-->
commit 90633e808c57ac222f9efeedf851500ec6133965
Author: Andrey Ryabinin
Date: Fri Jul 13 15:34:48 2018 +0300
mm/memcg:
Do we need it to RK as well for older kernels?
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 07/13/2018 02:28 PM, Andrey Ryabinin wrote:
Charges to offlined cgroup can happen. E.g. swapped
KSM page may charge to offlined cgroup. If such charge
races with reparenting
The commit is pushed to "branch-rh7-3.10.0-862.6.3.vz7.62.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-862.6.3.vz7.62.3
-->
commit efe4c8aa2739b381655e0d95a97b7937a3712b42
Author: Pavel Butsykin
Date: Fri Jul 13 15:28:40 2018 +0300
fs/fuse
On Fri, Jul 13, 2018 at 02:48:31PM +0300, Pavel Tikhomirov wrote:
> Criu algorithm is (prepare_mnt_ns):
> 1) Restore all mounts of the CT (from all mntns'es) in single temporary
> mount namespace.
> 2) For each mount namespace of the container recreate it's mounts:
> a) Unshare temporary mntns
Criu algorithm is (prepare_mnt_ns):
1) Restore all mounts of the CT (from all mntns'es) in single temporary
mount namespace.
2) For each mount namespace of the container recreate it's mounts:
a) Unshare temporary mntns (mounts are doubled)
b) Remove with pivot_root all excess mounts
So at some
Charges to offlined cgroup can happen. E.g. swapped
KSM page may charge to offlined cgroup. If such charge
races with reparenting during the offlining process
it may result in hang in mem_cgroup_reparent_charges()
Let's say we have cgroup A and cgroup B. A is parent of
B, B is offlined already,