리눅스 커널에 대한 Q&A 게시판 입니다. (비밀글 체크는 꼭 필요한 경우에만)
cgroup에 대해서 질문드립니다.
작성자
박성수
작성일
2024-01-14 23:36
조회
61
안녕하세요 문영일님. iamroot 20기에서 공부하고 있는 박성수입니다.
cgroup_early_init을 공부하던 중 cgroup 전체 자료구조에 대한 그림이 잘 안그려져서 질문드립니다.
제가 생각하기에 cgroup에서 궁극적으로 수행하려는 작업은 하나의 task를 하나의 cgroup가 연결시키는 작업이라고 이해했습니다.
그래서 일단 struct task_struck와 struct cgroup이 어떻게 연결되어 있는지에 대해서 살펴보고 있는 중입니다.
[질문 1] https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2020/01/05/cgroup-internlas
해당 자료의 그림을 참조해보면 task_struct는 하나의 css_set을 갖는데 css_set은 다시 cgrp_cset_link를 통해 cgroup과 연결되어 있는 것을 확인했습니다.
따라서 하나의 task와 하나의 cgroup은 중간의 css_set과 cgrp_cset_link를 통해 연결되어 있다는 것을 이해할 수 있었습니다.
struct cgrp_cset_link {
struct cgroup *cgrp;
struct css_set *cset;
struct list_head cset_link;
struct list_head cgrp_link;
};
그런데 cgrp_cset_link의 cgrp_link 필드의 역할에 대해서 잘 이해가 되지 않았습니다.
https://lwn.net/Articles/606925/
해당 자료의 Cgroups linkages 파트를 읽어보면
css_set.cset_links 필드와 cgrp_cset_link가 연결되어 해당 cgroup안에 있는 모든 task를 찾을 수 있게 해준다고 하는데요.
해당 부분은 kernel/cgroup/cgroup.c의 __cgroup_task_count 함수에서 cgroup에 연결된 모든 task 개수를 구하는 과정을 보면 명확히 이해할 수 있었습니다.
int __cgroup_task_count(const struct cgroup *cgrp)
{
....
list_for_each_entry(link, &cgrp->cset_links, cset_link)
count += link->cset->nr_tasks;
....
}
하지만 cgroup.cgrp_links 필드와 cgrp_cset_link가 연결되어 css_set안의 모든 cgroup을 찾을 수 있게 해준다는 말이 이해가 되지 않았습니다.
각 task는 css_set과 연결되어 하나의 cgroup을 가지게 되는데 해당 말의 의미는 하나의 task가 여러 cgroup과 연결되어 있다는 말인지 잘 모르겠습니다..
[질문 2] 위 내용을 바탕으로
하나의 cgroup에는 "css_set - cgrp_cset_link - cgroup" 한 세트가 존재하고 결국 이 한 세트가 task와 연결되는 구조가 맞는지 질문드립니다.
[질문 3] cgroup hierarchy에 대해서는 전혀 감이 안잡혀서 질문드립니다..
/sys/fs/cgroup/memory/A
/sys/fs/cgroup/memory/A/B
/sys/fs/cgroup/memory/A/C
이런식으로 계층이 생기는거 같은데 cgrp_dfl_root를 비롯하여 계층구조가 어떻게 구성되어 있는 것인지 잘 모르겠습니다..
[질문 4] 마지막으로 cgroup 안에는 여러 subsystem이 달려있는 것으로 이해했는데요. (cpu_cgrp_subsys, memory_cgrp_subsys 등등..)
이 subsystem들이 cgroup과 독립적으로 생성 및 소멸될 수 있는지 궁금합니다.
(예를들어, A cgroup의 memory_subsystem이 B cgroup의 memory_subsystem과 같을 수 있는지.. 입니다 )
Documentation/admin-guide/cgroup-v1/cgroup.rst를 확인해보면
It's not currently possible to bind a new subsystem to an active
cgroup hierarchy, or to unbind a subsystem from an active cgroup
hierarchy. This may be possible in future, but is fraught with nasty
error-recovery issues.
라는 말로 보아.. cgroup과 각각의 subsystem이 독립적으로 운용되지는 않을 것이라 생각되는데 혹시 맞는지 질문드립니다.
감사합니다.
cgroup_early_init을 공부하던 중 cgroup 전체 자료구조에 대한 그림이 잘 안그려져서 질문드립니다.
제가 생각하기에 cgroup에서 궁극적으로 수행하려는 작업은 하나의 task를 하나의 cgroup가 연결시키는 작업이라고 이해했습니다.
그래서 일단 struct task_struck와 struct cgroup이 어떻게 연결되어 있는지에 대해서 살펴보고 있는 중입니다.
[질문 1] https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2020/01/05/cgroup-internlas
해당 자료의 그림을 참조해보면 task_struct는 하나의 css_set을 갖는데 css_set은 다시 cgrp_cset_link를 통해 cgroup과 연결되어 있는 것을 확인했습니다.
따라서 하나의 task와 하나의 cgroup은 중간의 css_set과 cgrp_cset_link를 통해 연결되어 있다는 것을 이해할 수 있었습니다.
struct cgrp_cset_link {
struct cgroup *cgrp;
struct css_set *cset;
struct list_head cset_link;
struct list_head cgrp_link;
};
그런데 cgrp_cset_link의 cgrp_link 필드의 역할에 대해서 잘 이해가 되지 않았습니다.
https://lwn.net/Articles/606925/
해당 자료의 Cgroups linkages 파트를 읽어보면
css_set.cset_links 필드와 cgrp_cset_link가 연결되어 해당 cgroup안에 있는 모든 task를 찾을 수 있게 해준다고 하는데요.
해당 부분은 kernel/cgroup/cgroup.c의 __cgroup_task_count 함수에서 cgroup에 연결된 모든 task 개수를 구하는 과정을 보면 명확히 이해할 수 있었습니다.
int __cgroup_task_count(const struct cgroup *cgrp)
{
....
list_for_each_entry(link, &cgrp->cset_links, cset_link)
count += link->cset->nr_tasks;
....
}
하지만 cgroup.cgrp_links 필드와 cgrp_cset_link가 연결되어 css_set안의 모든 cgroup을 찾을 수 있게 해준다는 말이 이해가 되지 않았습니다.
각 task는 css_set과 연결되어 하나의 cgroup을 가지게 되는데 해당 말의 의미는 하나의 task가 여러 cgroup과 연결되어 있다는 말인지 잘 모르겠습니다..
[질문 2] 위 내용을 바탕으로
하나의 cgroup에는 "css_set - cgrp_cset_link - cgroup" 한 세트가 존재하고 결국 이 한 세트가 task와 연결되는 구조가 맞는지 질문드립니다.
[질문 3] cgroup hierarchy에 대해서는 전혀 감이 안잡혀서 질문드립니다..
/sys/fs/cgroup/memory/A
/sys/fs/cgroup/memory/A/B
/sys/fs/cgroup/memory/A/C
이런식으로 계층이 생기는거 같은데 cgrp_dfl_root를 비롯하여 계층구조가 어떻게 구성되어 있는 것인지 잘 모르겠습니다..
[질문 4] 마지막으로 cgroup 안에는 여러 subsystem이 달려있는 것으로 이해했는데요. (cpu_cgrp_subsys, memory_cgrp_subsys 등등..)
이 subsystem들이 cgroup과 독립적으로 생성 및 소멸될 수 있는지 궁금합니다.
(예를들어, A cgroup의 memory_subsystem이 B cgroup의 memory_subsystem과 같을 수 있는지.. 입니다 )
Documentation/admin-guide/cgroup-v1/cgroup.rst를 확인해보면
It's not currently possible to bind a new subsystem to an active
cgroup hierarchy, or to unbind a subsystem from an active cgroup
hierarchy. This may be possible in future, but is fraught with nasty
error-recovery issues.
라는 말로 보아.. cgroup과 각각의 subsystem이 독립적으로 운용되지는 않을 것이라 생각되는데 혹시 맞는지 질문드립니다.
감사합니다.
다음과 같이 답변을 참고하시기 바랍니다.
[답변1] cgroup 자료 구조는 cgroup이라는 구조체와 css_set이라는 구조체를 가지고 서로 연결하여 사용하지만 각각 관리하는 바가 다릅니다.
- cgroup 구조체는 하이라키(트리) 구조로 관리하고 각 엔트리(디렉토리)에서 설정들을 관리하고 있습니다.
- css_set 구조체는 cgroup에 관여하는 프로세스 집합 구조로 관리하고 있습니다.
cgroup <------(cgrp_cset_link)------> css_set와 같이 관리하며,
cset_link에는 cgroup이 보는 관점에서 관련된 css_set 구조체들을 리스트로 연결하여 관리하고 있습니다.
cgrp_link에는 css_set이 보는 관점에서 관련된 cgroup 구조체들을 리스트로 연결하여 관리하고 있습니다.
결국 cgrp_cset_link 구조체는 연결자로서 사용되고 있습니다.
[답변2] 질문과 같이 1(cgroup):1(css_set):1(task_struct) 구조가 아니며,
위 [답변1]과 같이 프로세스(task) 1개 이상이 css_set에 포함되고, 링크를 통해 관련된 cgroup이 1개 이상 있을 수 있습니다.
[답변3] cgroup을 이용할 때 하이라키(tree)구조로 만들어 사용하는 경우가 아니라면 cgrp_dfl_root를 바인딩하여 통쨰로 하나만 사용합니다.
[답변4] memcg 라는 서브시스템의 최상위 cgroup 부터 하이라키(tree) 구조로 A, B, C cgroup이 관리되고 있습니다.
cpuset이라는 서브시스템도 마찬가지로 cgrup이 하이라키(tree) 구조로 관리되고 있습니다.
이러한 디렉토리는 모두 서브시스템별로 독립적으로 이용합니다.
즉 memcg의 밑에 A라는 이름으로 생성한 cgroup 구조체와
cpuset의 밑에 동일하게 A라는 이름으로 생성한 cgroup 구조체는 서로 다릅니다. (이름만 같습니다)
* 저도 서버가 아닌 임베디드 위주로 시스템을 분석하다 보니, cgroup 자료 구조는 전체를 분석하지 않고 일부만 봤습니다. 따라서 기엑에 오류가 있을 수 있습니다. ^^;
감사합니다.