LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術

第48回cgroup v2から使うコントローラとmiscコントローラ

おひさしぶりです。今年はこれまで結局一回もこの連載の記事を書きませんでした。年末が近づきAdvent Calendarの季節になり、毎年参加しているAdvent Calendarの案内が今年もあったので、また記事でAdvent Calendarに参加しようと思い戻ってきました。この記事はLinux Advent Calendar 2021の21日目の記事です。

仕事が忙しかったりして、なかなかこの連載に手が回らなかった一方で、今年は2013年以来開催してきたコンテナの勉強会をオンラインで2回開催できました。4月にSeccompをテーマにした勉強会10月に「Rustとコンテナ」をテーマにした勉強会を開催しました。どちらもこの連載で触れてきたような基本的な内容からさらに深い内容、この連載では全く触れていない内容まで、非常に広く深いお話が聞ける勉強会になりました。どちらも動画がアーカイブ公開されていますので、ご興味のあるテーマがあればぜひご覧になってください。

さて、これまで7回にわたって、この連載でcgroup v2について紹介してきました。これまではcgroupを作ったり、それぞれのcgroupでどのようなコントローラを有効にしてリソース制限を行うか? といった、cgroupコア部分が持つ、cgroup自身の階層構造を構成する機能を中心に解説してきました。

今回から、実際のリソース制限を行うコントローラをcgroup v2でどのように使うか? といったところを紹介していきたいと思います。

コントローラの使い方と言っても、ほとんどのコントローラでは基本はcgroup v1のときと大きく変わりません。そこで、今回は操作方法を細かく説明するのではなく、cgroup v2のコントローラを全体的に見ながら、cgroup v1から制御方法が変わったところを紹介したり、cgroup v1から動きが変わったところをつまみ食いしながら軽く説明をしていきたいと思います。同時に最近追加された新しいコントローラについても紹介します。

cgroup v2で使えるコントローラ

現時点(5.15カーネル時点)でcgroup v2で使えるコントローラは次の通りです。

表1 cgroup v2で使えるコントローラ(5.15カーネル)
コントローラ名 使えるようになったバージョン
cpu 4.15
cpuset 5.0
device 4.15
freezer 5.2
hugetlb 5.6
io 4.5
memory 4.5
misc 5.13
perf_event 4.11
pids 4.5
rdma 4.11

5.13カーネルを使っており、デフォルトでcgroup v2のみがマウントされているUbuntu 21.10の環境では、root cgroup配下のcgroup.controllersは次のようになっています。

$ uname -r
5.13.0-21-generic
$ grep cgroup /proc/self/mountinfo
35 25 0:30 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot
$ cat /sys/fs/cgroup/cgroup.controllers 
cpuset cpu io memory hugetlb pids rdma misc

Ubuntu 21.10のような新しい環境では、上記のようにデフォルトでcgroup v2のみを使うようになっています。しかし現時点では、多くのシステムでcgroup v1のみがマウントされているか、cgroup v1とv2の両方がマウントされていると思います。

第37回で説明したとおり、cgroup v1とv2両方がマウントされている場合は、cgroup v1側で有効になっていないコントローラのみがcgroup v2で使えます。このような環境で特定のコントローラをcgroup v2で使いたい場合は、起動時にカーネルパラメータcgroup_no_v1=を使ってcgroup v2で使いたいコントローラを指定します。allを指定するとcgroup v1側では全コントローラが無効になります。

ここでcgroupを1つ作成し、/sys/fs/cgroup/cgroup.controllersに出現しているコントローラを全部、子cgroupで使えるようにしてみましょう。このあたりの操作方法については第38回をご覧ください。

$ sudo mkdir /sys/fs/cgroup/test
$ echo "+cpuset +cpu +io +memory +hugetlb +pids +rdma +misc" | sudo tee /sys/fs/cgroup/cgroup.subtree_control
(使えるコントローラすべてを子cgroupで使えるようにする)
+cpuset +cpu +io +memory +hugetlb +pids +rdma +misc
$ cat /sys/fs/cgroup/cgroup.subtree_control 
cpuset cpu io memory hugetlb pids rdma misc

このように、cgroup.subtree_controlファイルに子cgroupで使いたいコントローラを、コントローラ名の前に+をつけて書き込むと登録できました。登録すると、子cgroupでコントローラが有効になり、cgroupディレクトリ内にはコントローラ用のファイルが出現するのでした。この例ではcgroup.controllers内に書かれているコントローラすべてを書いています。実際は、Ubuntu 21.10ではデフォルトでいくつかコントローラは登録されていますので、このように全部を追加する必要はありません。

次のように、全コントローラをcgroup.subtree_controlに登録すると大量のファイルが出現します。

$ ls /sys/fs/cgroup/test/
cgroup.controllers      cpuset.cpus            hugetlb.1GB.events.local  io.stat              memory.stat
cgroup.events           cpuset.cpus.effective  hugetlb.1GB.max           io.weight            memory.swap.current
cgroup.freeze           cpuset.cpus.partition  hugetlb.1GB.rsvd.current  memory.current       memory.swap.events
cgroup.max.depth        cpuset.mems            hugetlb.1GB.rsvd.max      memory.events        memory.swap.high
cgroup.max.descendants  cpuset.mems.effective  hugetlb.2MB.current       memory.events.local  memory.swap.max
cgroup.procs            cpu.stat               hugetlb.2MB.events        memory.high          misc.current
cgroup.stat             cpu.uclamp.max         hugetlb.2MB.events.local  memory.low           misc.max
cgroup.subtree_control  cpu.uclamp.min         hugetlb.2MB.max           memory.max           pids.current
cgroup.threads          cpu.weight             hugetlb.2MB.rsvd.current  memory.min           pids.events
cgroup.type             cpu.weight.nice        hugetlb.2MB.rsvd.max      memory.numa_stat     pids.max
cpu.max                 hugetlb.1GB.current    io.max                    memory.oom.group     rdma.current
cpu.pressure            hugetlb.1GB.events     io.pressure               memory.pressure      rdma.max

ちなみにroot cgroup内を見てみると、次のようになっています。

$ ls -F /sys/fs/cgroup/
cgroup.controllers      cgroup.threads         dev-mqueue.mount/  memory.numa_stat                sys-kernel-config.mount/
cgroup.max.depth        cpu.pressure           init.scope/        memory.pressure                 sys-kernel-debug.mount/
cgroup.max.descendants  cpuset.cpus.effective  io.cost.model      memory.stat                     sys-kernel-tracing.mount/
cgroup.procs            cpuset.mems.effective  io.cost.qos        misc.capacity                   system.slice/
cgroup.stat             cpu.stat               io.pressure        -.mount/                        test/
cgroup.subtree_control  dev-hugepages.mount/   io.stat            sys-fs-fuse-connections.mount/  user.slice/

子cgroupよりはファイル数が大幅に少ないことがわかります。root cgroupはリソース制限が行えないので、基本的にはコントローラ用のファイルは出現しません。しかし、一部のコントローラ用のファイルについては、全体の統計情報を見れるようにroot cgroupに出現します。

rootでもroot以外でも、cgroup自体を操作したり、cgroup自体の情報を見るファイルはcgroup.で始まり、コントローラ用のファイルはコントローラ名が頭に付きます。

deviceコントローラ

ここで改めて先ほども見たcgroup.controllersファイルを見てみましょう。このファイルには使えるコントローラが一覧されています。

$ cat /sys/fs/cgroup/cgroup.controllers 
cpuset cpu io memory hugetlb pids rdma misc

先の表1とcgroup.controllersファイルを見比べると、deviceがないことに気づいた方もいらっしゃるのではないでしょうか。

cgroup.controllers内に記載がないからといって、cgroup v2でdeviceコントローラが使えないわけでも、Ubuntuカーネルでdeviceコントローラが有効になっていないわけではありません。

$ grep CGROUP_DEVICE /boot/config-5.13.0-21-generic 
CONFIG_CGROUP_DEVICE=y

cgroup v2からは、deviceコントローラには他のコントローラのようなインターフェースファイルがなくなり、最近流行の(?)eBPFプログラムをcgroupにアタッチして制限を行うようになりました。デバイスへのアクセスを行おうとすると、そのアタッチしたプログラムへ制御が移り、プログラムが成功もしくは失敗を返して制御を行います[1]⁠。

ネットワーク系コントローラ

cgroup v2で使えるコントローラを眺めると、cgroup v1にあったネットワーク系のコントローラがないことに気づきます。

cgroup v1には、ネットワーク処理の優先度を指定するnet_prioコントローラと、cgroup内のプロセスが作成したパケットにクラスIDを指定して、tcやiptablesで制御を行うnet_clsコントローラが存在しました。

このcgroup v1のnet_clsコントローラでIDを指定するには、

# mkdir /sys/fs/cgroup/net_cls/test
# echo 1 > /sys/fs/cgroup/net_cls/test/net_cls.classid

このように、対象とするcgroup配下のIDを指定するためのファイルnet_cls.classidファイルにIDを登録する必要がありました。

そして、このIDを登録したcgroupに対してiptablesを使って、次のようにフィルタリングを定義してフィルタリングできました。

# iptables -A OUTPUT --protocol icmp --destination 192.168.122.1 -m cgroup --cgroup 1 -j DROP
(cgroup v1のnet_clsを使って、指定したClass IDを指定してフィルタリングを設定)
# ping 192.168.122.1
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
^C
--- 192.168.122.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2054ms

現在はiptablesでcgroup v2の対応が進み、net_clsでIDを指定しなくても、直接cgroupのパスを指定してフィルタリングが行えるようになりました。

特にフィルタリングしない環境でpingが通っている環境があるとします。まずはcgroupを作成し、そのcgroupにシェルのPIDを登録します。

$ sudo mkdir /sys/fs/cgroup/test
$ echo $$ | sudo tee /sys/fs/cgroup/test/cgroup.procs 
995

そして、iptablesのcgroupモジュールで、cgroup v2のcgroupとしてのパスを--pathで指定してフィルタリングを設定します。

ここでは、さきほどpingが通っていた192.168.122.1に対するフィルタリングを、/test cgroupに対して--pathを使って設定します。

$ sudo iptables -A OUTPUT --protocol icmp --destination 192.168.122.1 -m cgroup --path /test -j DROP
$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       icmp --  *      *       0.0.0.0/0            192.168.122.1        cgroup /test

ここで指定するパスは、対象とするPIDの/proc/[PID]/cgroup内で確認できるcgroupとしてのパスです。今回の例だと/testということになります。

$ cat /proc/$$/cgroup 
0::/test

フィルタリングが設定された状態で、先ほどと同様にpingを実行してみます。

$ ping 192.168.122.1
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
^C
--- 192.168.122.1 ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18434ms

このようにフィルタリングされているのでエラーとなります。

もちろん、フィルタリングを削除すると元通りにpingでの疎通ができます。

$ sudo iptables -D OUTPUT --protocol icmp --destination 192.168.122.1 -m cgroup --path /test -j DROP
$ ping 192.168.122.1
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=0.183 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=0.778 ms
64 bytes from 192.168.122.1: icmp_seq=3 ttl=64 time=0.764 ms
^C
--- 192.168.122.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 0.183/0.575/0.778/0.277 ms

また、tcプログラムでeBPFプログラムをロードし、cgroupのパスをeBPFのデータ構造に保存し、tcがロードしたeBPFプログラム内でcgroupのパスを取得して制御の対象かどうかを判定できるようになっているようです。

このあたりのサンプルプログラムがカーネルソースのサンプルプログラムに含まれていますので、詳しくはそちらをご参照ください[2]⁠。

暗黙のうちに常に有効になるコントローラ

このほかに、cgroup v2では暗黙のうちに有効になるコントローラが存在します。

cgroupのコントローラを実装する際にはcgroup_subsysという構造体を実装します。この構造体のメンバ変数にimplicit_on_dflというboolの変数が存在します。

include/linux/cgroup-defs.h
struct cgroup_subsys {
    :(略)
        /*
         * If %true, the controller, on the default hierarchy, doesn't show
         * up in "cgroup.controllers" or "cgroup.subtree_control", is
         * implicitly enabled on all cgroups on the default hierarchy, and
         * bypasses the "no internal process" constraint.  This is for
         * utility type controllers which is transparent to userland.
         *
         * An implicit controller can be stolen from the default hierarchy
         * anytime and thus must be okay with offline csses from previous
         * hierarchies coexisting with csses for the current one.
         */
        bool implicit_on_dfl:1;
    :(略)

この変数がtrueに設定されたコントローラはcgroup v2では、次のように動作します。

  • cgroup v2ツリー上の全cgroupで暗黙のうちに有効となる
  • cgroup.controllerscgroup.subtree_controlにはコントローラ名がリストされない

ただし、cgroup v2でコントローラを使うには、cgroup v1ではコントローラが有効化されていないことが条件でした。つまりcgroup v1でコントローラが有効になっていない場合のみ、1つ目に挙げたようにcgroup v2のツリー全体の各cgroupでコントローラが有効になります。

また第39回で、cgroup v2でコントローラを有効にしてリソース分配を行う際には、末端のcgroupにしかプロセスが所属できないという制約があることを説明しました。cgroup v2ツリーのすべてのcgroupでコントローラが有効になるということは、implicit_on_dfltrueになっているコントローラは、この制約を受けないということです。

つまり、リソース制御のための制約の範疇外となることからもわかるように、この暗黙のうちに常に有効になるコントローラは、リソース制御を行うコントローラではなく、ユーティリティ系のコントローラのために設けられた機能です。

執筆時点(5.15カーネル)では、このimplicit_on_dfltrueになっているコントローラはperf_eventコントローラのみです。

kernel/events/core.c
struct cgroup_subsys perf_event_cgrp_subsys = {
    :(略)
        /*
         * Implicitly enable on dfl hierarchy so that perf events can
         * always be filtered by cgroup2 path as long as perf_event
         * controller is not mounted on a legacy hierarchy.
         */
        .implicit_on_dfl = true,
    :(略)
};

perfは主にLinuxでカーネルの性能に関する情報を収集し、分析するために使います。このperfを使う際に、cgroup内で動作しているプロセスに関するイベントのみをcgroupのパスを指定し、フィルタリングして取得できます。

ここで、cgroup v2では特別な操作なしで、perf_eventコントローラの機能を使えることを簡単に試して見ておきましょう。

まず、root cgroup直下にtestというcgroupを作成し、この/test cgroupを指定してperf statコマンドを実行します。perf statコマンドでcgroupを指定するには--cgroupまたは-Gオプションを使います。

$ sudo mkdir /sys/fs/cgroup/test
$ sudo perf stat -e task-clock --cgroup /test (/test を指定してperf statコマンドを実行)

ここで別のシェルを起動し、シェルのPIDを作成した/test cgroupに登録します。登録されたのを確認してyesコマンドを実行します。

$ echo $$ | sudo tee /sys/fs/cgroup/test/cgroup.procs
(シェルのPIDを/test cgroupに登録)
1116
$ cat /proc/self/cgroup (登録されたのを確認)
0::/test
$ timeout 3 yes > /dev/null (3秒間yesを実行)
$

ここでperf statを実行しているシェルに戻り、perf statを停止します。

$ sudo perf stat -e task-clock --cgroup /test
^C
 Performance counter stats for 'system wide':

          3,001.01 msec task-clock                /test #    0.263 CPUs utilized

      11.413407271 seconds time elapsed

このように/test cgroupを指定してイベントの取得ができています。

ここで、再度/test cgroupを指定してperf statを実行してから、さきほどのシェルを/test cgroupから削除し、yesコマンドを実行してみましょう。

$ echo $$ | sudo tee /sys/fs/cgroup/cgroup.procs
(シェルのPIDをroot cgroupに登録し、/test cgroupから削除)
1116
$ timeout 3 yes > /dev/null
$

そして/test cgroupを指定して実行しているperf statコマンドを停止してみましょう。

$ sudo perf stat -e task-clock --cgroup /test
^C
 Performance counter stats for 'system wide':

     <not counted> msec task-clock                /test

       6.955355876 seconds time elapsed

/test cgroupの外でyesコマンドを実行したので、perf statではデータが収集できていません。

このように、cgroup v2を使うとperf_eventコントローラが常に全cgroupで有効になるため、特別な操作を必要とせずにperfコマンドでcgroupごとのデータを収集できます。

perf stat以外でも、perf recordperf reportコマンドでもcgroupごとのデータを収集して表示させたりできます。

miscコントローラ

表1やここまでの実行例で、この連載ではこれまで全く紹介していないコントローラがあることに気づいた方もいらっしゃるのではないでしょうか。

そうです、miscコントローラです。このコントローラはcgroup v1でも使えます。以下ではcgroup v2での実行例を示しますが、cgroup v1でも同じように使えます。miscコントローラは5.13カーネルで導入されました。Ubuntu 21.10でroot cgroupにあるcgroup.controllersファイルを見ると、次のようにmiscという文字列が見えます。

$ cat /sys/fs/cgroup/cgroup.controllers 
cpuset cpu io memory hugetlb pids rdma misc

このコントローラは、ホスト上にある有限個のリソースの使用をcgroupで制限したい場合に使います。例えばシステム上に全部でリソースが10個あるとして、それを特定のcgroupやcgroupツリー内では3個まで使わせたい、といった制限に使用できます。

この機能を使いたい場合は、規則に沿ってカーネル内で実装を行うと、miscコントローラ用のインターフェースファイルに実装に従ってリソース制限を行うためのキーと値のペアが出現します。このようにシンプルなリソース制限を行うための汎用的な入れ物(コントローラ)が準備されたということです。

Ubuntu 21.10環境では、デフォルトではmiscコントローラはroot cgroupにあるcgroup.subtree_controlには登録されていませんので、子cgroupで使えるようにするにはまず登録が必要です。

$ echo "+misc" | sudo tee /sys/fs/cgroup/cgroup.subtree_control 
+misc (子cgroupでmiscコントローラを使えるようにする)
$ cat /sys/fs/cgroup/cgroup.subtree_control 
cpuset cpu io memory pids misc (登録された)

この状態で、子cgroupを作成すると、miscコントローラように次のようにインターフェースファイルが2つ出現します。

$ sudo mkdir /sys/fs/cgroup/test (子cgroupを作成する)
$ ls /sys/fs/cgroup/test/misc.* (misc用に2つファイルが出現する)
/sys/fs/cgroup/test/misc.current  /sys/fs/cgroup/test/misc.max

また、この他にroot cgroupに1つ、miscコントローラ用のファイルがあります。

$ ls /sys/fs/cgroup/misc.*
/sys/fs/cgroup/misc.capacity (root cgroupに存在するmiscコントローラ用ファイル)

これらのインターフェースファイルは表2のような機能を持っています。

表2 miscコントローラ用インターフェースファイル
ファイル名 機能
misc.capacity root cgroupのみに出現する読み取り専用ファイル。miscコントローラで制御するホスト上のリソース名と、そのリソースの総量が表示されます
misc.current root cgroup以外に出現する読み取り専用ファイル。cgroupとその子孫のcgroupで使われている量が表示されます
misc.max root cgroup以外に出現する読み書き可能なファイル。cgroupとその子孫で使えるリソースの制限値を表示・設定します
misc.events root cgroup以外に出現する読み取り専用ファイル。cgroupとその子孫で制限値を超えようとした回数(5.16カーネルから)

miscコントローラは、執筆時点(5.15カーネル)では仮想マシンのメモリを暗号化して保護するAMDのSEVや、SEV-ESで使われるASIDというアドレス空間のID数を制限するための機能のみが使っています。

筆者の手元にはこの機能が使える環境がありませんので、出現しているファイルの中身を見ても空です。

$ cat /sys/fs/cgroup/misc.capacity 
$ cat /sys/fs/cgroup/test/misc.*

このように具体例を示せませんので、説明のために仮想的な例を挙げて説明したいと思います。ここでは、例としてmiscコントローラでres_ares_bという2つのホスト上のリソースが制御できるようになっているとしましょう。

ホスト上ではres_aが10個、res_bが5個使用できるとします。このとき、root cgroupにあるmisc.capacityの中身は次のようになるでしょう。

$ cat /sys/fs/cgroup/misc.capacity
res_a 10
res_b 5

test cgroupで、res_aを3個、res_bは使っていない場合、/sys/fs/cgroup/test/misc.currentは次のようになります。

$ cat /sys/fs/cgroup/test/misc.current`
res_a 3
res_b 0

test cgroupでは、res_aは制限なし、res_bは3個までという制限を設定したい場合は、次のように書き込みます。

# echo res_a max > /sys/fs/cgroup/test/misc.max (res_aの制限を無制限に設定する)
# echo res_a 3 > /sys/fs/cgroup/test/misc.max (res_bの制限を3に設定する)
$ cat /sys/fs/cgroup/test/misc.max (制限値の確認)
res_a max
res_b 3

実際のmiscコントローラの定義と使用

ここまで仮想的な例で説明しましたので、最後に執筆時点でのmiscコントローラに関係する定義をコード上で確認しておきましょう。

miscコントローラでリソースを制御したい場合、まずはinclude/linux/misc_cgroup.h内のenum misc_res_typeでリソースを定義します。

include/linux/misc_cgroup.h
/**
 * Types of misc cgroup entries supported by the host.
 */
enum misc_res_type {
#ifdef CONFIG_KVM_AMD_SEV
    /* AMD SEV ASIDs resource */
    MISC_CG_RES_SEV,
    /* AMD SEV-ES ASIDs resource */
    MISC_CG_RES_SEV_ES,
#endif
    MISC_CG_RES_TYPES
};

ここではMISC_CG_RES_SEVMISC_CG_RES_SEV_ESが定義されています。

同様にkernel/cgroup/misc.c内のmisc_res_nameで、先のenumと同じ順序でリソース名を定義します。

kernel/cgroup/misc.c
/* Miscellaneous res name, keep it in sync with enum misc_res_type */
static const char *const misc_res_name[] = {
#ifdef CONFIG_KVM_AMD_SEV
    /* AMD SEV ASIDs resource */
    "sev",
    /* AMD SEV-ES ASIDs resource */
    "sev_es",
#endif
};

このように、現時点ではsevsev_esというリソースが定義されています。リソースをコントロールしたいモジュールなどは、リソースを使用する前にmisc_cg_set_capacity関数を呼び出し、システム上に存在するリソースの総量を設定します。設定した値がmisc.capacityに表示されます。

sevsev_esの場合は、arch/x86/kvm/svm/sev.c内のsev_hardware_setup関数内で、このcapacityを設定しています。

arch/x86/kvm/svm/sev.c
    sev_asid_count = max_sev_asid - min_sev_asid + 1;
    if (misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count))
        goto out;

リソースを使用する場合は、misc_cg_try_charge関数でリソースを確保するようで、sev.c内でもsev_asid_new関数でリソースを1つ確保するようになっています。

arch/x86/kvm/svm/sev.c
    sev->misc_cg = get_current_misc_cg();
    ret = misc_cg_try_charge(type, sev->misc_cg, 1);

まとめ

今回はcgroup v2で使えるコントローラのcgroup v1からの変化と、5.13カーネルで新たに加わったコントローラであるmiscコントローラについて説明しました。

cgroup v2では、net_clsコントローラのように周辺のツールでのサポートが拡張された結果、cgroup v2ではコントローラ自体が現れなかったり、cgroup v1から採用されているファイルを用いた制限値の設定や確認ではなく、eBPFを使った制限を行うように変化していることがおわかりいただけたと思います。

今回の記事を書くに当たり、udzuraさんにレビューをしていただきました。そして、udzuraさんにcgroupを指定してperfコマンドを使う方法を教えていただきました。ありがとうございました。

次回も、もう少しcgroup v2でのコントローラについて紹介していく予定です。

おすすめ記事

記事・ニュース一覧