Memory Resource Controller Implementation Memo

구현 메모의 기준과 범위

이 문서는 2010년 2월에 갱신된 Memory Resource Controller(Memcg) 구현 메모이며 base kernel은 `2.6.33-rc7-mm(candidate for 34)`입니다. VM과 memcg behavior가 복잡해 internal 동작을 설명하지만 implementation detail은 바뀔 수 있습니다.

page_cgroup과 swap_cgroup

Usage 기록에는 page마다 하나인 `page_cgroup` object와 `swp_entry`마다 하나인 `swap_cgroup` entry를 사용합니다.

Charge와 uncharge entry points

Page 또는 `swp_entry` charge는 `mem_cgroup_try_charge()`에서 `usage += PAGE_SIZE`로 수행합니다.

try·commit·cancel 두 단계 charge

Memcg page charge는 `mem_cgroup_try_charge()` 뒤 `mem_cgroup_commit_charge()` 또는 `mem_cgroup_cancel_charge()`로 끝나는 두 단계 transaction입니다. 아래 설명은 `CONFIG_SWAP=y`를 가정합니다.

Anonymous page swap-in/out state

Anonymous page는 `MAP_ANONYMOUS` mapping의 page fault 또는 Copy-On-Write에서 새로 allocate됩니다. Swap-in 때 page는 swap cache에서 오며, 새로 allocate해 read한 SwapCache라 charge가 없거나 이미 process에 map되어 charge된 두 경우가 있습니다.

Page cache와 shmem charge

일반 page cache는 `filemap_add_folio()`에서 charge됩니다. Migration은 뒤 절에서 다룹니다. `__filemap_remove_folio()`는 `filemap_remove_folio()`와 `__remove_mapping()`에서 호출됩니다.

Shmem의 자세한 state transition은 `mm/shmem.c`에서 확인합니다. Leaf shmem page는 inode radix-tree, SwapCache 또는 swap-in/out 중 두 곳 모두에 존재할 수 있습니다.

Page migration과 per-memcg LRU

Page migration entry point는 `mem_cgroup_migrate()`입니다.

작은 limit·shmem·NUMA migration test

Race test에서는 GB보다 xKB 또는 xxMB처럼 작은 memcg limit이 더 효과적입니다. GB와 MB 범위의 memory behavior가 매우 달라 작은 limit test에서 많은 race가 발견됐습니다.

Shmem은 page cache이면서 SwapCache가 될 수 있어 역사적으로 memcg handling 문제가 많았습니다. 따라서 shmem/tmpfs test는 항상 가치가 있습니다.

	is useful. Following is a sample script to do migration::

		mount -t cgroup -o cpuset none /opt/cpuset

		mkdir /opt/cpuset/01
		echo 1 > /opt/cpuset/01/cpuset.cpus
		echo 0 > /opt/cpuset/01/cpuset.mems
		echo 1 > /opt/cpuset/01/cpuset.memory_migrate
		mkdir /opt/cpuset/02
		echo 1 > /opt/cpuset/02/cpuset.cpus
		echo 1 > /opt/cpuset/02/cpuset.mems
		echo 1 > /opt/cpuset/02/cpuset.memory_migrate

	In above set, when you moves a task from 01 to 02, page migration to
	node 0 to node 1 will occur. Following is a script to migrate all
	under cpuset.::

		--
		move_task()
		{
		for pid in $1
		do
			/bin/echo $pid >$2/tasks 2>/dev/null
			echo -n $pid
			echo -n " "
		done
		echo END
		}

		G1_TASK=`cat ${G1}/tasks`
		G2_TASK=`cat ${G2}/tasks`
		move_task "${G1_TASK}" ${G2} &

Memory hotplug·nested cgroup·mixed controller test

Memory hotplug은 page migration을 쉽게 시험하는 방법입니다. `/sys/devices/system/memory/memoryXXX/state`에 `offline`을 써서 XXX 위치 memory를 offline합니다.

	memory hotplug test is one of good test.

	to offline memory, do following::

		# echo offline > /sys/devices/system/memory/memoryXXX/state

Nested test는 `/opt/cgroup/01/child_a`와 `child_b`를 만들고 parent 01과 child_b에 limit을 둔 뒤 두 child에서 job을 실행합니다. Job이 도는 동안 `child_aa`, `child_bb`, `child_c`를 무작위 생성·삭제하고 새 group에도 job을 시작합니다.

9.6 Mount with other subsystems
-------------------------------

	Mounting with other subsystems is a good test because there is a
	race and lock dependency with other cgroup subsystems.

	example::

		# mount -t cgroup none /cgroup -o cpuset,memory,cpu,devices

	and do task move, mkdir, rmdir etc...under this.

swapoff와 memcg OOM test

Swap management는 memcg의 복잡한 부분이며 `swapoff` 중 swap-in call path는 일반 swap-in과 다르므로 명시적으로 test해야 합니다.

	(Shell-A)::

		# mount -t cgroup none /cgroup -o memory
		# mkdir /cgroup/test
		# echo 40M > /cgroup/test/memory.limit_in_bytes
		# echo 0 > /cgroup/test/tasks

	Run malloc(100M) program under this. You'll see 60M of swaps.

	(Shell-B)::

		# move all tasks in /cgroup/test to /cgroup
		# /sbin/swapoff -a
		# rmdir /cgroup/test
		# kill malloc task.

	Of course, tmpfs v.s. swapoff test should be tested, too.

Tmpfs와 swapoff 조합도 함께 test해야 합니다. Memcg limit으로 발생한 OOM은 해당 memcg 또는 hierarchy 아래 task를 kill해야 하며 `panic_on_oom`을 호출하거나 다른 group의 task를 kill하면 안 됩니다.

9.8 OOM-Killer
--------------

	Out-of-memory caused by memcg's limit will kill tasks under
	the memcg. When hierarchy is used, a task under hierarchy
	will be killed by the kernel.

	In this case, panic_on_oom shouldn't be invoked and tasks
	in other groups shouldn't be killed.

	It's not difficult to cause OOM under memcg as following.

	Case A) when you can swapoff::

		#swapoff -a
		#echo 50M > /memory.limit_in_bytes

	run 51M of malloc

	Case B) when you use mem+swap limitation::

		#echo 50M > memory.limit_in_bytes
		#echo 50M > memory.memsw.limit_in_bytes

	run 51M of malloc

Charge migration과 threshold notification

Task migration과 함께 task에 연결된 charge도 옮길 수 있습니다. Group A에서 memory를 사용한 program을 실행하고 group B의 `memory.move_charge_at_immigrate`를 1로 설정한 뒤 PID를 B의 `tasks`에 쓰면 charge가 이동합니다.

	(Shell-A)::

		#mkdir /cgroup/A
		#echo $$ >/cgroup/A/tasks

	run some programs which uses some amount of memory in /cgroup/A.

	(Shell-B)::

		#mkdir /cgroup/B
		#echo 1 >/cgroup/B/memory.move_charge_at_immigrate
		#echo "pid of the program running in group A" >/cgroup/B/tasks

	You can see charges have been moved by reading ``*.usage_in_bytes`` or
	memory.stat of both A and B.

`move_charge_at_immigrate`에 쓸 값의 의미는 `Documentation/admin-guide/cgroup-v1/memory.rst` 8.2절을 참고합니다.

Memory controller threshold는 cgroup notification API로 구현됩니다. `tools/cgroup/cgroup_event_listener.c`를 사용해 memory usage가 5M threshold를 오르내릴 때마다 event message가 오는지 시험합니다.

9.10 Memory thresholds
----------------------

	Memory controller implements memory thresholds using cgroups notification
	API. You can use tools/cgroup/cgroup_event_listener.c to test it.

	(Shell-A) Create cgroup and run event listener::

		# mkdir /cgroup/A
		# ./cgroup_event_listener /cgroup/A/memory.usage_in_bytes 5M

	(Shell-B) Add task to cgroup and try to allocate and free memory::

		# echo $$ >/cgroup/A/tasks
		# a="$(dd if=/dev/zero bs=1M count=10)"
		# a=