Linux 커널에서 cpuset cgroup 상속 의미론과 관련된 "문제"는 무엇입니까?

여기에 있는 커널 버그 추적기에는 명확하고 해결되지 않은 CPUset 문제가 하나 이상 문서화되어 있습니다.

오류 42789- cpuset cgroup: CPU가 오프라인 상태가 되면 모든 cgroup의 cpuset.cpus에서 제거되지만, 온라인 상태가 되면 루트 cpuset.cpus로만 되돌아갑니다.

견적으로 이동코멘트티켓에서(실제 제출에 하이퍼링크를 추가하고 스팸 봇을 방지하기 위해 IBM 이메일 주소를 제거했습니다):

이는 Prashanth Nageshappa가 독립적으로 보고했으며 커밋에서 수정되었습니다.8f2f748b0656257153bcf0941df8d6060acc5ca6, 그러나 나중에 Linus에 의해 커밋으로 되돌아갔습니다.4293f20c19f44ca66e5ac836b411d25e14b9f185. 약속한 대로 수정으로 인해 다른 곳에서 회귀가 발생했습니다.

수정 커밋(나중에 되돌림)은 문제를 잘 설명합니다.

현재 CPU 핫플러그 중에 cpuset 콜백은 시스템 상태를 반영하도록 cpuset을 수정하며 이 처리는 비대칭입니다. 즉, CPU가 오프라인 상태가 되면 모든 CPU세트에서 제거됩니다. 그러나 다시 온라인 상태가 되면 루트 CPUset에만 다시 배치됩니다.

이로 인해 일시 중지/재개 중에 심각한 문제가 발생했습니다. 일시 중지 중에는 부팅되지 않는 모든 CPU를 오프라인으로 전환하고 다시 시작하는 동안 다시 온라인으로 전환합니다. 즉, 복구 후에는 모든 cpuset(루트 cpuset 제외)가 하나의 CPU(boot CPU)로 제한됩니다. 그러나 일시중단/재개의 전체 목적은 시스템을 일시중단 전 상태에 최대한 가깝게 복원하는 것입니다.

---

다음과 같이 상속과의 관계에 대한 추가 통찰력과 함께 동일한 비대칭 핫 플러그 ​​문제를 설명합니다.

오류 188101- cgroup의 cpuset에 있는 프로세스 스케줄링이 제대로 작동하지 않습니다.

해당 티켓을 인용하려면:

컨테이너의 cpuset(docker/lxc는 모두 기본 cgroup을 사용함)가 비어 있게 되면(hotplug/hotunplug로 인해) 해당 컨테이너에서 실행 중인 프로세스는 가장 가까운 비어 있지 않은 조상의 CPUset에 예약될 수 있습니다.

그러나 실행 중인 컨테이너의 cpuset를 업데이트(echo 메서드 사용)하여 실행 중인 컨테이너(docker/lxc)의 cpuset가 비어 있는 상태에서 비어 있지 않은 상태로 변경되면(빈 cpuset에 CPU 추가) 해당 컨테이너에서 실행되는 작업은 다음과 같습니다. 프로세스는 여전히 가장 가까운 비어 있지 않은 조상과 동일한 CPUSet을 사용합니다.

---

cpuset에 다른 문제가 있을 수 있지만 위의 내용은 "커널 논리의 상속 의미 체계가 손상되었기 때문에" systemd가 cpuset을 노출하거나 이용하지 않는다는 것을 이해하고 이해하는 데 충분합니다.

이 두 가지 버그 보고서로 판단하면 복구 후 CPU가 CPUset에 다시 추가되지 않을 뿐만 아니라예(수동으로) 추가하면 해당 cgroup의 프로세스는 cpuset이 허용하지 않는 CPU에서 계속 실행됩니다.

---

내가 찾은Lennart Petling의 메시지이는 이에 대한 이유를 직접적으로 확인합니다(굵게).

Lennart Poettering은 2016년 8월 3일 수요일 16:56 +0200에 다음과 같이 썼습니다.

2016년 8월 3일 수요일 14:46에 Werner Fink 박사(suse.de의 werner)가 다음과 같이 썼습니다.

v228의 문제(현재 git 로그의 이후 AFAICS인 것 같습니다)는 반복되는 CPU 핫플러그 이벤트(오프라인/온라인)입니다. 근본 원인은 CPUset.cpus를 가공으로 복원할 수 없다는 것입니다. libvirt는 허용되지 않기 때문에 이를 수행할 수 없습니다.

이는 커널 cpuset 인터페이스의 제한사항이며,이것이 현재 systemd에서 cpuset을 노출하지 않는 이유 중 하나입니다.다행히도 systemd의 CPUAffinity=를 통해 노출되는 CPU 선호도 제어인 cpuset에 대한 대안이 있습니다. 이는 본질적으로 동일한 작업을 수행하지만 의미가 덜합니다.

우리는 systemd에서 cpuset을 직접 지원하고 싶지만 커널 인터페이스가 지루한 한 그렇게 하지 않을 것입니다. 예를 들어,현재 시스템이 일시 중지/재개 주기를 거치면 CPU 세트가 완전히 플러시됩니다.

나는 명확한 답변을 제공하기 위해 cgroup에 대해 충분히 알지 못하지만 (그리고 확실히 2013년에 cgroup에 대한 경험이 없습니다!) Ubuntu 16.04 cgroups v1에서는 함께 작동하는 것 같습니다.

sudo /bin/bash나는 루트에서 분리된 하위 프로세스를 사용하여 다른 사용자에게 포크를 강제하는 작은 테스트를 설계했습니다. &이 -H플래그는 편집증이 심하여 sudo루트의 홈 환경에서 실행을 강제합니다.

cat <(whoami) /proc/self/cgroup >me.cgroup && \
sudo -H /bin/bash -c 'cat <(whoami) /proc/self/cgroup >you.cgroup' & \
sleep 2 && diff me.cgroup you.cgroup

이는 다음을 생성합니다.

1c1
< admlocal
---
> root

참고로 내 시스템의 cgroup 마운트 구조는 다음과 같습니다.

$ mount | grep group
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
lxcfs on /var/lib/lxcfs type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
$

Linux 커널에서 cpuset cgroup 상속 의미론과 관련된 "문제"는 무엇입니까?

"현재 유닛 속성으로 노출되는 cgroup 속성의 수는 제한되어 있습니다. 나중에 커널 인터페이스가 정리되면 확장될 예정입니다. 예를 들어커널 로직의 상속 의미가 깨졌기 때문에 현재는 cpuset이나 Freeze가 전혀 노출되지 않습니다.. 또한, 런타임 시 유닛을 다른 슬라이스로 마이그레이션하는 것(즉, 실행 중인 유닛의 Slice= 속성 변경)은 현재 커널에 원자성 cgroup 하위 트리 이동이 부족하기 때문에 지원되지 않습니다. "

그렇다면, cpuset 커널 로직의 상속 의미 체계에 어떤 문제가 있습니까(그리고 이것이 CPU와 같은 다른 cgroup 컨트롤러에는 어떻게 적용되지 않습니까)?

위의 굵은 인용문이 우려됩니다. 즉, 여기서 참조된 cgroup v1 cpuset을 사용하면 어떤 "gotchas"(gotchas)가 가능합니까?

매우 짧은 대답: 코드가 다중 처리에서 잘 작동하지 않고, 다른 프로세스가 PID를 사용하고 해제하여 하위 프로세스의 PID가 종료되기 전에 풀로 반환합니다. 따라서 업스트림에서 PID의 하위 프로세스가 살아 있다고 믿게 됩니다. 따라서 PID는 다음과 같습니다. 건너뛰었지만 하위 항목을 종료하기 전에 PID를 다시 게시해서는 안 됩니다. 간단히 말해서 자물쇠가 좋지 않습니다.

서비스, ​​범위 및 조각은 관리자가 자유롭게 만들거나 프로그램을 통해 동적으로 만들 수 있습니다. 이는 시작 중에 운영 체제에서 설정한 기본 슬라이스를 방해할 수 있습니다.

Cgroup을 사용할 때 프로세스와 모든 하위 프로세스는 포함 그룹에서 리소스를 얻습니다.

그리고더 많은 것이 있습니다...긴 답변으로 이어집니다...

많은 사람들이 우려를 표명했습니다.

1. "Linux 제어 그룹이 작동하지 않습니다"(2016) 조나단 드 보인 폴라드:

   "작업" 추상화를 제공하는 운영 체제 커널은 전체 "작업"을 취소/종료하는 방법을 제공합니다. 증인 Win32TerminateJobObject()예를 들어 메커니즘.

   systemd가 cgroup의 모든 프로세스를 종료할 때 단일 "작업 종료" 시스템 호출을 실행하지 않습니다. 그와 같은 일은 없다. 하지만 그것은애플리케이션 패턴 코드의 루프 내부cgroup의 모든 프로세스 ID를 반복적으로 스캔하고(PID 번호로 가득 찬 파일을 다시 읽어서) 이전에 볼 수 없었던 새로운 프로세스에 신호를 보냅니다. 여기에는 몇 가지 문제가 있습니다.

   • systemd는 프로세스 그룹에서 하위 프로세스를 가져오는 프로세스보다 속도가 느려서 종료 신호가 정확히 잘못된 프로세스로 전송될 수 있습니다. systemd는 cgroup의 프로세스 목록 파일을 읽고 실제로 프로세스 목록에 신호를 보내기 시작합니다. ...

   ...

   • cgroup 내에서 새 프로세스를 신속하게 포크하는 프로그램은 이론적으로 올바른 "날씨"가 우세한 한 오랜 시간 동안 시스템 실행을 유지할 수 있습니다. 각 루프 반복에서 프로세스가 종료되어야 하기 때문입니다. 이것이 반드시 포크 폭탄일 필요는 없다는 점에 유의하십시오. systemd가 루프를 실행할 때마다 cgroup에서 최소한 하나의 새로운 프로세스 ID를 볼 수 있도록 충분히 포크하면 됩니다.

   • systemd는 신호를 보낸 프로세스의 프로세스 ID를 세트로 유지하여 어떤 프로세스가 신호를 다시 보내려고 시도하지 않는지 파악합니다. ID N이 있는 프로세스는 reaper/부모 프로세스에 의해 신호를 받고 프로세스 테이블에서 지워진 다음 cgroup의 무언가가 새 프로세스를 다시 포크하고 동일한 프로세스 ID N을 다시 할당할 수 있습니다. systemd는 cgroup의 프로세스 ID 목록을 다시 읽고 새 프로세스에 신호를 보냈다고 생각하며 전혀 신호를 보내지 않습니다.

    

   이러한 문제는 모두 실제 "작업" 메커니즘을 통해 해결됩니다. 그러나 cgroups에서는 그렇지 않습니다. cgroup은 기존 Unix 리소스 제한 메커니즘을 개선하여 오래 지속되고 잘 알려진 일부 설계 결함을 해결하도록 설계되었습니다. VMS와 동일하게 설계되지 않았거나Windows NT 작업 개체.

   아니요, 냉장고는 답이 아닙니다. systemd는 Freezer를 사용하지 않을 뿐만 아니라 systemd"라고 명확하게 설명되어 있습니다.커널 논리의 상속 의미 체계가 손상되었습니다.".그게 무슨 뜻인지 물어봐야 해., 그러나 이들에게 Freezer는 마술처럼 cgroup을 작동 메커니즘으로 전환하지 않습니다.

   또한 Docker와 다른 사람들이 자신의 목적을 위해 제어 그룹의 고정 상태를 조작할 것이며 원자 읽기 및 업데이트와 같이 이 설정을 여러 소유자 간에 공유할 수 있는 실제 경합 메커니즘이 없다는 점은 말할 것도 없습니다.
   _{마지막으로 수정된 날짜 스탬프가 유지되는 한 이 웹페이지를 수정되지 않은 원본 형식으로 복사 및 배포할 수 있는 권한이 부여됩니다.}

   • TerminateJobObject()기능

     Terminates all processes currently associated with the job. If the  
     job is nested, this function terminates all processes currently  
     associated with the job and all of its child jobs in the hierarchy. 
     

   • Windows NT 작업 개체

     A job object allows groups of processes to be managed as a unit.  
     Job objects are namable, securable, sharable objects that control  
     attributes of the processes associated with them. Operations  
     performed on a job object affect all processes associated with the  
     job object. Examples include enforcing limits such as working set   
     size and process priority or terminating all processes associated 
     with a job.
     

   이것 답변 공급조나단의 설명은 다음과 같습니다.

   Systemd의 리소스 제어 개념

   ...

   서비스, ​​범위 및 슬라이싱 단위는 cgroup 트리의 객체에 직접 매핑됩니다. 이러한 유닛이 활성화되면 각 유닛은 유닛 이름에서 생성된 cgroup 경로에 직접 매핑됩니다(일부 문자 이스케이프 모듈로). 예를 들어 foobar-waldo.slice 슬라이스의 quux.service 서비스는 cgroup foobar.slice/foobar-waldo.slice/quux.service/에 있습니다.

   서비스, ​​범위 및 조각은 관리자가 자유롭게 만들거나 프로그램을 통해 동적으로 만들 수 있습니다. 그러나 기본적으로 운영 체제는 시스템을 시작하는 데 필요한 여러 가지 기본 제공 서비스를 정의합니다. 또한 기본적으로 4개의 슬라이스가 정의됩니다. 첫 번째는 루트 슬라이스인 .slice(위에서 언급한 대로)와 system.slice, machine.slice 및 user.slice입니다. 기본적으로 모든 시스템 서비스는 첫 번째 슬라이스에 배치되고 모든 가상 머신 및 컨테이너는 두 번째 슬라이스에 배치되며 사용자 세션은 세 번째 슬라이스에 배치됩니다. 하지만,이는 단지 기본값일 뿐이며 관리자는 자유롭게 새 슬라이스를 정의하고 서비스와 범위를 할당할 수 있습니다. 또한 모든 로그인 세션은 VM 및 컨테이너 프로세스와 마찬가지로 별도의 범위 단위에 자동으로 배치됩니다. 마지막으로, 로그인한 모든 사용자는 모든 세션 범위가 배치되는 자체 암시적 슬라이스도 갖게 됩니다..

   ...

   보시다시피 서비스와 범위에는 프로세스가 포함되어 있으며 슬라이스에 배치되는 반면, 슬라이스에는 자체 프로세스가 포함되어 있지 않습니다. 또한 특수한 "-.slice"는 암시적으로 전체 트리의 루트로 식별되므로 표시되지 않습니다.

   서비스, ​​범위 및 조각에 대해 동일한 방식으로 리소스 제한을 설정할 수 있습니다. ...

전체 설명을 보려면 위의 링크를 클릭하세요.

2. "Cgroups v2: 두 번째로 리소스 관리가 더 나빠졌습니다." (2016년 10월 14일) davmac 작성:

   ...

   그룹이 다른 그룹 내에 존재하도록 중첩 계층을 생성할 수 있으며, 중첩 그룹은 상위 그룹의 리소스를 공유합니다(추가로 제한될 수 있음). 프로세스의 PID를 그룹의 제어 파일 중 하나에 기록하여 프로세스를 그룹으로 이동할 수 있습니다. 따라서 그룹에는 프로세스와 하위 그룹이 포함될 수 있습니다.

   제한해야 할 두 가지 확실한 리소스는 메모리와 CPU 시간이며, 각각에는 "컨트롤러"가 있지만 다른 리소스(예: I/O 대역폭)가 있을 수 있으며 일부 Cgroup 컨트롤러는 실제로 리소스 활용도를 관리하지 않습니다. (예: "냉동고" 컨트롤러/하위 시스템) Cgroups v1 인터페이스를 사용하면 다양한 컨트롤러가 연결된 여러 계층을 생성할 수 있습니다(이 값은 의심스럽지만 가능성은 있습니다).

   중요한 점은 프로세스가 상위 프로세스로부터 cgroup 멤버십을 상속받으며 적절한 권한이 없으면 cgroup에서 스스로 이동할 수 없다는 것입니다. 즉, 프로세스는 포크로 인해 부과된 제한을 피할 수 없습니다. RLIMIT_AS(주소 공간) 제한을 사용하여 프로세스의 메모리 사용을 제한할 수 있지만(예를 들어) 프로세스를 분기할 수 있고 그 자식이 프로세스에서 시작하지 않고도 추가 메모리를 소비할 수 있는 setrlimit의 사용과 이를 비교하십시오. 원본 자원 추출 프로세스. 반면에 Cgroup을 사용하면 프로세스와 모든 하위 프로세스가 포함 그룹에서 리소스를 가져옵니다.

   ...

   cgroup 컨트롤러는 단순히 시스템 관리 의사 파일 시스템에 제어 손잡이를 추가하기 때문에 공개 API로 허용되지 않는 많은 손잡이를 구현합니다. cgroup은 적절하게 추상화되거나 정제되지 않은 인터페이스 손잡이로 끝나고 커널 내부 세부 정보를 직접적으로 드러냅니다.

   이러한 노브는 제대로 정의되지 않은 위임 메커니즘을 통해 개별 애플리케이션에 노출되어 필요한 조사 없이 공용 API를 구현하는 지름길로 cgroup을 효과적으로 남용합니다.

   ...

   cgroup v1에서는 스레드가 모든 cgroup에 있을 수 있도록 허용합니다. 이는 상위 cgroup에 속한 스레드와 그 하위 스레드가 리소스를 놓고 경쟁하는 흥미로운 문제를 야기합니다. 서로 다른 두 유형의 엔터티 간에 경쟁이 있고 이를 해결할 확실한 방법이 없기 때문에 이는 짜증나는 일입니다. 컨트롤러마다 다른 작업을 수행합니다.

3. cgroup v2 문서도 참조하세요: "v1의 문제점과 v2의 기본 원리":

   여러 계층

   cgroup v1은 여러 계층을 허용하며 각 계층은 원하는 수의 컨트롤러를 호스팅할 수 있습니다. 이는 높은 수준의 유연성을 제공하는 것처럼 보이지만 실제로는 그다지 유용하지 않습니다.

   예를 들어 모든 계층에서 사용 가능한 냉장고와 같은 유틸리티 컨트롤러는 각 컨트롤러의 인스턴스가 하나만 있기 때문에 하나의 계층에서만 사용할 수 있습니다. 이 문제는 일단 계층 구조가 채워지면 컨트롤러가 다른 계층 구조로 이동할 수 없다는 사실로 인해 더욱 악화됩니다. 또 다른 문제는 계층 구조에 바인딩된 모든 컨트롤러가 정확히 동일한 계층 구조 보기를 갖도록 강요된다는 것입니다. 특정 컨트롤러를 기반으로 세분성을 변경할 수 있는 방법은 없습니다.

   실제로 이러한 문제는 동일한 계층에 배치할 수 있는 컨트롤러를 심각하게 제한하며 대부분의 구성은 각 컨트롤러를 자체 계층에 배치하는 데 의존합니다. 밀접하게 관련된 컨트롤러(예: CPU 및 CPUACCT 컨트롤러)만 동일한 계층 구조에 있는 것이 합리적입니다. 이는 종종 사용자 공간이 계층 관리 작업이 필요할 때마다 각 계층에서 동일한 단계가 반복되어 여러 개의 유사한 계층을 관리하게 된다는 것을 의미합니다.

   또한 여러 계층 구조를 지원하려면 비용이 많이 듭니다. 이는 핵심 cgroup 구현을 크게 복잡하게 하지만 더 중요한 것은 다중 계층에 대한 지원이 cgroup이 일반적으로 사용되는 방식과 컨트롤러가 수행할 수 있는 작업을 제한한다는 것입니다.

   존재할 수 있는 계층의 수에는 제한이 없습니다. 이는 스레드의 cgroup 멤버십을 유한한 길이로 설명할 수 없음을 의미합니다. 키에는 원하는 수의 항목이 포함될 수 있고 길이가 무제한이므로 조작이 매우 어렵고 구성원을 식별하기 위한 컨트롤러를 추가하게 되어 계층 수가 폭발적으로 증가하는 원래 문제가 악화됩니다.

   또한 컨트롤러는 다른 컨트롤러가 위치할 수 있는 계층 구조의 토폴로지에 대해 어떤 기대도 할 수 없으므로 각 컨트롤러는 다른 모든 컨트롤러가 완전히 직교하는 계층 구조에 연결되어 있다고 가정해야 합니다. 이로 인해 컨트롤러 간의 협업이 불가능하거나 적어도 매우 번거로워집니다.

   대부분의 사용 사례에서는 서로 완전히 직교하는 계층 구조에 컨트롤러를 배치할 필요가 없습니다. 종종 원하는 것은 특정 컨트롤러에 따라 다양한 수준의 세분성을 갖는 기능입니다. 즉, 특정 컨트롤러에서 볼 때 계층 구조가 리프에서 루트로 축소될 수 있습니다. 예를 들어 특정 구성에서는 특정 수준 이상으로 메모리가 할당되는 방식에 관심이 없지만 여전히 CPU 주기가 할당되는 방식을 제어하려고 할 수 있습니다.

자세한 내용은 3부 링크를 참조하세요.

4. 2016년 7월 20일 수요일 12:53에 Lennart Poettering(시스템 개발자)과 Daniel P. Berrange(Redhat) 간의 통신, 검색됨systemd-devel 파일제목은 "[systemd-devel] cpuset 컨트롤러를 통해 모든 프로세스를 CPU/RAM으로 제한":

   2016년 7월 20일 수요일 오후 12:53에 Daniel P. Berrange(redhat.com의 berrange)가 다음과 같이 썼습니다.

   가상화된 호스트의 경우 모든 호스트 운영 체제 프로세스를 CPU/RAM 노드의 하위 집합으로 제한하고 나머지는 QEMU/KVM에서만 사용할 수 있도록 남겨 두는 것이 종종 바람직합니다. 역사적으로 사람들은 이 작업을 수행하기 위해 "isolcpus" 커널 매개변수를 사용했지만 작년에는 그 의미가 변경되어 여기에 나열된 모든 CPU도 스케줄러에 의한 로드 밸런싱에서 제외되어 일반적으로 실시간 사용에 매우 유용하게 되었습니다. QEMU 스레드가 CPU 간 로드 밸런싱을 원하는 경우.

   따라서 유일한 옵션은 cpuset cgroup 컨트롤러를 사용하여 프로세스를 제한하는 것입니다. AFAIK, systemd는 현재 cpuset 컨트롤러를 명시적으로 지원하지 않으므로 향후 systemd 버전에서 문제가 발생할 위험을 최소화하면서 systemd에서 이를 구현하는 "최상의" 방법을 찾으려고 노력하고 있습니다.

   2016년 7월 20일 수요일 오후 3시 29분 30초 +0200에 Lennart Poettering이 답변했습니다.

   예, 현재는 이를 지원하지 않지만 지원하고 싶습니다. 그러나 문제는 현재 커널 인터페이스가 매우 지루하다는 것이며, 이 문제가 해결될 때까지 systemd에서 이를 지원할 가능성이 낮다는 것입니다. (내가 Tejun을 아는 한, cpuset에서 mem과 CPU의 관계는 동일하게 유지되지 않을 수 있습니다.)

   다음 메시지

   2016년 7월 20일 수요일 14:49에 Daniel P. Berrange(redhat.com의 berrange)는 다음과 같이 썼습니다.

   cgroupsv2는 distro가 전환되면 많은 문제를 일으킬 수 있으므로 작은 업데이트로 이 작업이 수행되지는 않을 것입니다. 새로운 주요 distro 버전일 뿐이므로 걱정할 필요가 없습니다.

이것이 명확해지기를 바랍니다.