최근 한 2주정도를 계속 게임과 미드에 몰입하던 터라 흥미로운 기사가 몇개 있었음에도 불구하고
그냥 '에이 제껴 어차피 일주일단위로 공개되는데 구지 내가....' 라는 마인드로 넘겨버리고 있었는데...
오늘은 좀 무료한 감이 있더라..(금방 질리는 게임불감증 ㅠㅠ)
그래서 그냥 여러가지 외국 기사들 보며 맥주나 마시던 중 Cgroup 내용이 있어서 살짝 소개하려고 한다.
대략 3년여 전 ( Korea Linux conf ) 부터 CGroup ( Control Group ) 은 새로운 버젼의 API 를 위해
준비해 오고 있었는데, 이 새로운 버젼에 대해난 대부분의 동작은 정상적으로 수행되고 있지만
쓰레드 레벨의 컨트롤에 대한 의견불일치 등 CPU controller 부분에서는 논란이 심했다고 한다.
필자는 기사에서 컨트롤그룹의 "쓰레드 모드" 는 더 많은 논란을 낳았지만, 사실 희망적 부분도 보인다고 역설했다.
기존 컨트롤 그룹에서는 딱히 스레드부분과 프로세스부분들을 구분하지 않았는데... (라고 하는데 내가 CGroup 을 실전에서 안다룬지 너무 오래되서 기억이 안나... 근데 그랬던거같음 -_-)
새로운 버젼에서는 이 부분이 크게 개선될 것이라고 한다.
일단, 기존에 ( 2013년 한국 리눅스컨퍼러스에서 ) 정리되었던 내용들중 Cgroup 의 Mistake 들에 대한 이해가 필요하므로 아래 링크를 참조해 볼 필요가 있다. ( 무려!!!! 우리나라 최초의 Full time Kernel commiter 인 태준님이 메인픽쳐를 장식하신다!! )
대략 계층별 Resource control 에 대한 상당한 논제들이 오고가는것을 알 수 있다.
이 기사 역시 이 계층관리에 대한 것을 주목하고 있다.
새로 변경될 API 에서는 이 계층관리를 아주 철저하게 하기 시작한다. Parent Process 와 Threads 간 구분을 명확하게 하지 않으면, 상위 레벨의 RG(resource group) 에 대한 구분에 오버헤드가 발생하고, 이를 구현하고 관리하는 것은 매우 비용이 많이 들어가는 부분이라는 점이다. (위에 태준님이 세상에 공짜는 없다..라는 식의 발언을 한다. ㅎㅎㅎ)
어쨋든, 몇몇 컨트롤 그룹은 이전보다 유연하게 구동되고 있다고 한다.
물론 개발자 입장에서 CPU 컨트롤러는 가장 상위에 존재할 수 밖에 없고, 같은 프로세스 내에서도 각 쓰레드끼리 서로 다른 정책을 적용하거나 경쟁해야 할 상황들이 요구되기도 하는데,
이에 따라 일부 사용자들이 이런 개별적 정책 관리가 필요하다고 생각하고 있음에도 불구하고, 새로운 Control group 에서는 이 기능을 제거해 버려 당황스럽다는 불만이 생긴 것이다.
그래서 이런 부분에 대한 새로운 제안들은 몇가지 있었으나, 오래 유지되지 못하였고, 아직까지 합의점을 찾지 못하고 있다고 한다.
CGroup 의 메인테이너인 태준님(+_+) 께서 최근 시도하신 것이 바로 이 논란의 "쓰레드모드" 인데,
Application control 아래 각각 새로운 Resource Group 을 생성하는 것보다, 계층구조의 각 노드에 쓰레드를 표기하는 식의 내부적 확장을 이용하는 것이 효율적이라는 것이다.
예를들어 아래와같은 구조가 일반적인 계층구조라면,
A 그룹에 Process 1, B 그룹에 Process 2, 3 가 존재한다고 볼 수 있다.
P2 에서 만약 쓰레드들이 여럿 동작하는 경우 이 쓰레드들은 P3 와 같은 레벨의 B 그룹에 포함 될 것이다. 이것은 P2 의 모든 스레드들이 P3 와 동일하게 여겨지는 결과를 일으키게 된다. 또한 쓰레드인지 아닌지 확인하여 부모 프로세스 레벨에 대한 자원계산도 필요하다.
반면, 쓰레드 모드의 경우, CG 아래에 스레드임을 표현하여 쓰레드와 비 쓰레드 프로세스간의 구분을 시켜줄 수 있다는 점이다.
예를 들면, 현재 B 그룹에 따로 P2,P3 를 지정하지 않고, Thread point 를 설정한 뒤,
그 아래 다시 쓰레드와 개별 프로세스로 나눠 관리할 수 있다는 것이다.
아래 그림을 보자 :
방금 설명한대로, A 그룹에는 P1, B 그룹에는 Thread Point 1 을 생성한 뒤, Thread 2 와 P3 를 할당하였다. TP (Thread Point) 2 는 P2 프로세스를 특정한다.
이는 B Group 에 대한 정책을 각 쓰레드 또는 프로세스별로 계산하여 사용할 수 있음을 나타낸다. 또한 P3 는 Non-Threaded 프로세스임을 확인 할 수 있게 된다.
즉, B group 의 경우 아래의 Thread 와 프로세스 모두 각각 컨트롤 할 수 있는 기회가 생긴다.
또한 하위계층의 Thread 들은 몇개가 생성되었든지, 상위 계층이 어떻게 구분되고 제어되는지 알 필요도 없고, 알 수 도 없기 때문에, 상위 계층에 의한 리소스 제어를 잘 따를 수 있게 된다.
여기까지 보면 참 완벽한 것 같았지만,
CPU Scheduler 에 대한 관리를 담당하고 있는 Peter Zijlstra 입장에서는 이는 다소 불합리한 케이스가 생길 수 있다고 주장하였다.
그는 루트 시스템. 즉, 커널단위에서 직접 생성이 될 필요가 있는 스레드들의 관리에 대해 집중하였고 그가 필요로하는 구조는 아래와 같았다.
이런 구조가 필요한 경우는 대부분 가상화 된, - 특히 Container 형태 또는 KVM 등 모듈형 기반의 - 스케쥴링의 경우이며, 이 경우 해당 프로세스의 레벨을 낮추거나 계층화시키기 위해서는 조금 더 처리비용이 소모된다. 또한 태준님의 현재 제안된 "Thread mode" 에서는 구현이 불가능한 구조인 것이다.
왜냐면 애초에 "스레드 모드" 는 각 노드(그룹) 아래에 확장플래그 형태로 관리되므로,
상위의 다른 프로세스들과 합쳐지는 것이 불가능하도록 설계되어 있기 때문이고,
이것을 수용 한다면, "No internal Process" 라는 규칙을 어기게 되어 스레드그룹이 삭제될 경우 하위 프로세스들이 상위 권한(루트) 으로 동작되게 될 수 있는 문제를 갖고 있다는 점이다. ( No Internal Process 라는 룰이 무엇인지 사실 정확히 모르겠다... 니미럴 공부를 더 해야하나.... )
이런 문제를 가지고 허태준님과 Zijilstra 는 한참 논쟁을 벌였고, 특히 Zijilstra 는 강경하게 자신의 케이스들을 거론하였다고 한다.
하지만, 태준님께서는 한가지 절충안을 제안하였다. 그것은 쓰레드 계층과 비 쓰레드 계층이 같은 그룹을 공유하고 있을때, 임의의 다른 그룹(노드)을 만들어 그 아래에 재배치 시키는 방법이다.
예를들어, 위에서 그림과 같이 루트에 바로 T1 을 연결시키는 것 대신, 숨겨진 C 라는 그룹을 생성하여 그 하위에 위치시키는 것이다. 비록 C 그룹에 대해서 명시적으로 나타나지 않는다고 해도 해당 쓰레드가순수하게 루트그룹에 속하는 일은 피할 수 있기 때문이다.
필자는, 이 Zijilstra 라는 메인테이너의 의도는, 사실 쓰레드 그룹이 비 쓰레드 그룹까지 포함 할 수 있도록 하위 유연성 구조를 원한 것이였나 본데,
이를 위해서는 트리계층의 확장 후, 다시 하위계층에서 상위계층을 재탐색 해야 하는 등의 복잡성이 발생하기 때문에 아주 강력한 필요성이 제시되지 않는 한 받아들여지기 어려운 부분이 있을 것이라고 전했다.
새로운 제안에 대한 검증코드는 곧 발표되고 배포될 예정이라고 하며, 이 시도 및 논쟁이 옳고 그름을 떠나서, 원래 가던 길을 벗어난 긴 여정이 될 수도 있다는 의견을 나타내며 필자는 마무리 하였다.
-----
우리나라의 기라성같은 은둔고수들중에 가장 유명해진(?) Full time kernel hacker 인 허태준님께서 메인테이너로 개발하고 있는 CGroup 에 대한 내용이라서 내가 실전에서 사용한지 너무 오래되서 가물가물한 지식임에도 불구하고, 다루어 보았다.
현재 커널개발에 대해서 상당히 여러부분에 걸쳐 다양한 변화 및 움직임이 일어나고 있음을 알려주기 위해서이며, 우리나라에선 혁신이란 말을 유행처럼 쓰지만, 외래문화를 바탕으로 두고 있는 사람들- 그냥 외국인 - 의 경우, 정말 필요할 때 자신을 깨부숴 갈 의향을 알리며 사용한다는 말임을 이해해야 한다는 것을 말하고 싶다.
![[Control-group hierarchy]](https://static.lwn.net/images/2017/cgtm1.png)
![[Control-group hierarchy]](https://static.lwn.net/images/2017/cgtm2.png)
![[Control-group hierarchy]](https://static.lwn.net/images/2017/cgtm3.png)